Ü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.
Hozzászólások
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
Forgalomról statisztika nincs?
--
+1
Lehet valami bot próbál bejelentkezni vagy egyéb hasonló jóság...
http://postimg.org/gallery/d4rtsz5g/59a66833/
http://postimg.org/image/kcxnyf4nh/240ca8d3/
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
Ez gáz. Tuti, hogy optimalizálással ezen sokat tudsz fogni...
--
PtY - www.onlinedemo.hu, www.westeros.hu
Apache processek száma nem túl sok. Apache.log rendelkezésre áll?
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...?
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.)
én is kérek abból, amit szívsz
Nem az Apache eszi meg a memóriát, hanem a benne futó szar memleak -es alkalmazás!
----
올드보이
+1
Javasolt php_fpm megfelelően konfigolva. (Már ha php-s cucc fut azon az apacson.)
+1
Azt azért kétlem, hogy a php_fpm -től megjavulna a kód... ;)
Inkább a programozót kell hátba vágni, illetve a php.ini -t tekergetni még a fejlesztői site -on
----
올드보이
A kód nem javul meg, de meg lehet fogni a bugos site-ot.
Ez nem feltétlenül van így. :)
De az igaz, hogy ez a leggyakoribb ok.
--
PtY - www.onlinedemo.hu, www.westeros.hu
Mondj egy másikat.
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
A lényeg hogy szar a kolléga munkája és nem a webszerver hibája.
Amúgy ki a tosz nem használ indexeket mindenhol? Minden DB probléma megoldás topicban az első amit beléd vernek. Állás interjún is gyakran várják ezt a választ DB kérdéseknél.
Erre még reagálni akarok majd.
szerk.: alattam leírták.
Ahol sok insert vagy update van, ott az index nem lesz problémás?
Attól függ, mit/miket indexelünk, és mekkora a tábla. nem beszélve a db backendről és az index típusáról.
De igen, okozhat problémát.
--
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.
+1 és egyszerre 3000 user tolja bele az adatot/módosít. ilyenkor kell db oldalon bohóckodni sokat, a nyomorult koder nem sokat tehet. Persze ő kapja az első pofont, hogy szar az app...
--
PtY - www.onlinedemo.hu, www.westeros.hu
Ebben a példában a posztoló nem tűnt kódernek. Persze ha valaki csak megírja a kódot, commitol majd vár hogy valaki más kezdjen valamit a kódjával 2 nap múlva az más kategória.
Én is írtam úgy kódot karrierem során hogy lövésem sem volt milyen vason fut. Fogalmam sincs miért néz ki így a piac nagy része.
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
Hogyne, ahol ezek problémát okoztak, ott nyilván nem voltak hajlandóak áldozni erre.
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