Apache megesz minden ramot

UNIX kezdő

Üdv,

A webszerverem (ubuntu 12.04 lts, apache 2.2.2, 3 GB Ram, 3 GB swap) mostanában elkezdte azt játszani, hogy minden előjel nélkül felzabálja a ramot és a swapet is, aminek a vége az lesz, hogy a gép ott vergődik a processek kilövésével, de sose tud annyit lelőni, hogy visszaálljon. Normál működés közben kb 60% ramot eszik, ami hirtelen felugrik és összedönt mindent (az volt a vicces amikor a kernel legelőször a syslog processt lőtte ki..)

Syslog:
http://pastebin.com/pWcg7RCj

Látom hogy az apache eszi meg, de viszont az apache error logjában sincs semmi releváns

Apache error log az első syslog bejegyzéstől:
[Fri Sep 18 17:36:14 2015] [info] [client xx.xx.xxx.xxx] (70007)The timeout specified has expired: core_output_filter: writing data to the network

Hogy tudnám kideriteni mi eszi meg a gépet? Új tartalom nem került fel, és van hogy már naponta 2x elhasal.

Előre is köszönöm.

  • 2745 megtekintés

( segej | 2015. 09. 18., p – 21:41 )

elég karcsú az erőforrás, mindazonáltal javaslom, hogy kontrolláld, hogy mennyit zabálhat és problem solved, részemről ubuntut nem szeressem így nem is ismerem, nem tudom, van-e már az általad használtban cgroup-ra lehetőség, ha igen, mission done, ha nem, akkor passz (részemről)

Nekem az apache-omban 2GB van. Zömében https-es oldalakat szolgál ki, van rajta mod_sec, mod_evasive, mod_pagespeed, 512M lefoglalva memcached-nek, 128M OPcode cache, és még nem fogyott el a memóriája. A statikus tartalmakat a pagespeed más URL-re irányítja, ahol nginx memóriába cache-elve osztja ki (512M van az nginx alatt, de ahogy a zabbix grafikonokat nézem, közel fele ennyivel is meg lenne elégedve).
Az oldalakat kiszolgáló MySQL másik gépen van.
A memóriazabálás mögött lehet alkalmazásprobléma, rosszul megírt sql query, rossz sql adatbázis, sokinden, em feltétlenül az apache beállításokban kell keresni a hibát. Az is lehet, hogy túl sok a http query, és túl hosszú a timeout. A várakozási idők egyszerűen, a query-k meg valami ratelimittel.
Azokat az siteokat, ahol egy oldal betöltéséhez 15-20 requestnél többre van szükség (html/js/css/képek/stb. összesen), meg mindenképpen optimalizálni kell.
--
PtY - www.onlinedemo.hu, www.westeros.hu

( dotnetlinux | 2015. 09. 19., szo – 09:12 )

Apache processek száma nem túl sok. Apache.log rendelkezésre áll?

( dotnetlinux | 2015. 09. 19., szo – 09:13 )

Mi van mögötte? PHP vagy CGI? Nem az van rosszul configurálva és egy-egy HTTPD process annyi memóriát eszik, mint egy ERP rendszer...?

( tbs v | 2015. 09. 19., szo – 09:31 )

Hardver? Mindene tökéletes? Raid? IOvihar? Ssh eltömése? Iptables flood protect jellegű konfig? (10+ éve egy gépemen az eltömött ssh megette a procit - ami megette az mdraid-et - ami megette az IO-t (onnantól no log) - ami megette a memóriát/swap-et - amitől megállt mint a szög.)

( Kayapo | 2015. 09. 19., szo – 10:07 )

Nem az Apache eszi meg a memóriát, hanem a benne futó szar memleak -es alkalmazás!

----
올드보이

Túl sok http hívás kell az oldal betöltéséhez (sok kép, sok js, sok css), rosszul szervezett sql fut a lekérdezéskor (ez db oldali hiba is lehet, pl. indexek hiánya), túlterhelt sql backend.
És pl. a rosszul megírt sql query-t sem feltétlenül tartom programozástechnikai hibának. A SQL-eket optimalizáló szaki és aki a kódot írja, normális esetben két ember - ez két szakterület. De ez szubjektív vélemény.
Nyilván nem azt akarom mondani, hogy aki az egyikhez ért, és jó benne, nem érthet a másikhoz is, csak azt, hogy ez nem feltétlenül van így.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Aha. :) Ez webre nagyon nem igaz minden esetben, csak a kb. readonly tábláknál. :) Az nagyon vidám amikor a mondjuk 500k soros táblán mondjuk 3mp az index újraépítés és 1-2mp-enként van benne változás. Természetesen a fejlesztők ilyen jönnek a lassúaszerver c. eposszal, de ez már egy másik topik.

Itt alapvetően arra próbáltam utalni, hogy ahol webre kell kitolni az infót, ott kritikus arra törekedni hogy a kód gyorsan fusson és jó válaszidővel. Ha forgalom nagy, akkor még a normálformákat is bőven fel lehet áldozni adatbázis szinten, mert olcsóbbra jön ki. Egy jól megírt kód esetén legfeljebb azt mondja az admin hogy hát igen, ez az egyprocis sata diszkes gép ennyit tud, tessék alátolni valami izmosabbat. Egy rossz kódnál, ahol persze ez ordít, mert mondjuk 50MB-os SQL result seten még PHP-ból sortol az illető vagy csak az első 10 sort használja, ott szoktak nézni, hogy jéééé ez a otthon i7-esem úgy szaladt, hogy csak na. Elfelejtődik, hogy a konkurrens 10 felhasználó miatt mindenféle lockok vannak az adatbázison, illetve eleve okoz terheltséget.

Vagy hogy éppen clusteren fut a kód, és lehet, hogy a következő request már másik vason fut le.
Ezért szoktam mondogatni nem egyszer, hogy leszarom, hogy a fejlesztő gépén hogyan produkál az app. Az élessel (lehetőleg minél inkább) megegyező környezeten kell produkálni ugyanazt az eredményt. És ez még mindig nem ugyanaz, mint amikor többezer távoli kliens dolgozik egyszerre az alkalmazással.
A valósággal megegyező véletlenszerűséget és forgalmat nagyon nehéz előidézni.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Kellően nagy vagy komolyan gondolt rendszernél már ez általában legalább részben belefér a büdzsébe. Inkább akkor van baj, amikor az jön, "jajjhát ez ilyen"? Példul mikor hirtelen 10GB-nyi SQL adattal szeretnének dolgozni. :) Sajnos ez utóbbival sokszor találkozom és jön az "ezzel kezdjél valamit légyszives" c. őrület.

Jahajj volt egy kedvencem. :) Elég szerteágazó oldal, több 10k-s nagyságrendű dinamikus aloldallal volt az alapszitu. Az alapjárat szerint keresők indexelése olyan 4-5 körüli loadot és igen érezhető terhelést generált és volt vas bőségesen alatta. :) A kód sem volt egy csoda, de azzal a mennyiségű forgalommal nemnagyon lehetett volna csodát tenni plusz erőforrás bevonása nélkül.

Sokszor lehet tenni üzemeltetői oldalról is dolgokat (mint pl. a statikus tartalmak elirányítása, optimalizálás, adatbázis oldalon meg a lekérdezés és az írás szétválasztása - igaz, ez utóbbihoz az alkalmazást is idomítani kell -, ill. a különböző cache-elések.
A régi webszerveremen 4mag volt 4GB-tal, és ugyanúgy haldoklott, mint a topikindítóé. Most fele annyi CPU/RAM van az apache alatt (igaz, van mellette egy static, de az kb 0 erőforrást eszik), és atomstabilan megy.
Közben az oldalak zömét https alá tettem, és a CPU átlagosan 2%-on megy. Holott - a topikindító grafikonjait nézve - az össz látogatottság a többszöröse az övének.
Ám, ha valami ennek ellenére mégis halódik, ott már üzemeltetői szinten nem sokat lehet tenni.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Az is lehet, hogy kisebb/nagyobb terhelésre lett optimalizálva, ennek megfelelően más az erőforrásigénye.
Vica-verza. Bármi lehet. Nem húznám le azonnal.
DB kérdéseknél a normalizálás is elhangzik, csak épp nagyon nem mindegy, hogy milyen az alkalmazás karakterisztikája, lehet, hogy többet ártunk vele, mint használunk. Szóval nem húznám a vizes lepedőt kapásból a fejlesztőre.
--
PtY - www.onlinedemo.hu, www.westeros.hu