Apache2 - DOS voorkomen

Hoe goed zijn je script geoptimaliseerd? Ik heb zo'n indruk dat ze veel geheugen gebruiken en dat ze vrij lang duren.

DOS of DDOS?

Al gekeken naar Fail2Ban; wordt er vaak ingezet om automagisch een hoog aantal requests van 1 IP te blokkeren.

Zo te zien loop je nogal keihard te swappen, ik zou proberen wat aan het geheugengebruik te doen van verschillende dingen (apache, mysql, update-apt niet draaien op dat moment). Verder zou ik je robots.txt aanpassen zodat search spiders niet teveel requests doen (rate limiting).

Kortom, wat ik hier zie is puur een geheugenprobleem, want je zit op dit moment gewoon keihard te swappen = dodelijk voor je performance.

Om geheugen te besparen zou je Apache kunnen inruilen voor een lichtere server zoals lighttpd of nginx.

8088 schreef op zondag 01 januari 2012 @ 17:47:
Om geheugen te besparen zou je Apache kunnen inruilen voor een lichtere server zoals lighttpd of nginx.

En anders keep-alive uitzetten en/of php in fastcgi-modus draaien.

300ms voor een pagina is ook vrij lang.

Mocht je nog een keer het probleem ondervinden kun je eens een fullstatus van Apache opvragen. Hieruit wordt al beter duidelijk wat er exact gebeurd.

500M voor een Apache + MySQL + Memcached + APC server is niet bepaald veel...

MySQL wil al redelijk wat gebeugen gebruiken, Apache is niet heel zuinig. APC probeert alles in z'n geheugen te houden en Memcached is ook specifiek alleen geheugenintensief. Naast het draaien van al dit spul heb je ook nog je webrequests waarbij (waarschijnlijk dus) veel geheugen gebruikt wordt.

Ik zou dus gewoon wat meer geheugen bestellen... 512MB is niet meer van deze tijd

Wolfboy schreef op zondag 01 januari 2012 @ 21:31:
512MB is niet meer van deze tijd

Voor een niet al te druk vBulletin forum is 512MB meer dan toereikend. Het moet alleen wel slim benut worden. Het geheugen uitbreiden is slechts symptoombestrijding en nodeloze geldverspilling als er niet eerst naar andere (voor de hand liggende) opties gekeken wordt.

[ Voor 29% gewijzigd door 8088 op 01-01-2012 21:43 ]

8088 schreef op zondag 01 januari 2012 @ 21:42:
[...]

Voor een niet al te druk vBulletin forum is 512MB meer dan toereikend. Het moet alleen wel slim benut worden. Het geheugen uitbreiden is slechts symptoombestrijding en nodeloze geldverspilling als er niet eerst naar andere (voor de hand liggende) opties gekeken wordt.

Heb je goed gezien hoeveel er in de swap zit ten opzichte van het fysieke geheugen?
Daarnaast is 512MB echt niet meer dan toereikend voor de situatie die YopY heeft. Veder is meer geheugen vaak een goedkopere en sneller optie om resultaat te boeken.

Erkens schreef op zondag 01 januari 2012 @ 21:49:
Heb je goed gezien hoeveel er in de swap zit ten opzichte van het fysieke geheugen?

Ja.

8088 schreef op zondag 01 januari 2012 @ 21:42:
Voor een niet al te druk vBulletin forum is 512MB meer dan toereikend. Het moet alleen wel slim benut worden. Het geheugen uitbreiden is slechts symptoombestrijding en nodeloze geldverspilling als er niet eerst naar andere (voor de hand liggende) opties gekeken wordt.

Helemaal mee eens.

Screenshot in de TS heeft veel tasks; ik neem aan dat je mpm-prefork gebruikt en ~140+ Apache processen draaien? MaxClients heb je in ieder geval nog niet (juist) configured; hiermee zou je thrashing mee moeten voorkomen (48%sy 22%wa komt voornamelijk door kswapd zo te zien).

Daarmaast kun je kiezen uit any of:

• KeepAliveTimeout verlagen
• Je scripts fixen, als requests lang duren
• ipv. mpm-prefork mpm-worker draaien; threads schalen iets beter dan forks (echter, de PHP-manual over mpm-worker).

Mocht dat niet helpen, dan zou je Apache kunnen swappen voor nginx (zoals iemand al suggereerde). Enige vereiste is dat je al je content onder dezelfde user served.

Alleen je totale MySQL geheugen gebruik (swap + res = virt) is al ca. 1,5x je fysieke geheugen, en elke apache instance gebruikt doodleuk ca. 0.5x je fysieke geheugen.

Je swaparea die in gebruik is is 3,5x je fysieke geheugen (van de 8x in totaal beschikbaar), dus idd of minder geheugen slobberende daemons gebruiken/scripts optimaliseren of meer RAM toevoegen (en afgaande op het huidige gebruik zou ik dan minstens naar 2GB RAM gaan).

Keeper of the Keys schreef op maandag 02 januari 2012 @ 12:07:
Alleen je totale MySQL geheugen gebruik (swap + res = virt) is al ca. 1,5x je fysieke geheugen

Nee. Je fysieke geheugengebruik kun je terugvinden onder RES; VIRT bevat ook mmap'ed files, shared(!) libraries en allocated stack/heap.

Pas op, RES is verradelijk. RES laat alleen zien wat je daadwerkelijk aan fysiek geheugen gebruikt. Zodra je begint te swappen dan daalt RES voor het proces dat uitgeswapt wordt. Als je bij mysql "5900 bytes" ziet betekend dat dus niet dat MySQL slecht 5900 bytes nodig heeft, maar dat er nog maar 5900 bytes over zijn en dat de rest is uitgeswapt.

Dat is ook een goede. En over swap zegt de developer van htop:

It is not possible to get the exact size of used swap space of a process. Top fakes this information by making SWAP = VIRT - RES, but that is not a good metric, because other stuff such as video memory counts on VIRT as well (for example: top says my X process is using 81M of swap, but it also reports my system as a whole is using only 2M of swap. Therefore, I will not add a similar Swap column to htop because I don't know a reliable way to get this information (actually, I don't think it's possible to get an exact number, because of shared pages).

Zodra TS z'n geheugengebruik weer op orde heeft kun je dus pas weer zien wat MySQL echt gebruikt.

Zo te zien is je bottleneck geheugen. Als je dan opcode caching gebruikt (dit moet allemaal in het geheugen worden geplaats!), dan snij je jezelf daarmee in de vingers. Dingen als APC/Memcached en zelfs MySQL-caching vreten geheugen. Dat soort grappen worden meestal alleen uitgehaald als je enorm CPU-bounded bent en/of veel geheugen over hebt. Ik zou opcode caching uitzetten en alleen zeer conservatieve MySQL-caching doen. Dan kom je nog geheugen tekort waarschijnlijk, maar dan is de kans kleiner dat je processen starven en helemaal niet meer antwoorden.

Hoeveel trafiek krijgt deze website te verwerken? Hoeveel is het in de piekmoment? Hoeveel is het minimum en hoeveel tijdens je zogenaamde 'DOS'?
Heb je er na de IP block van Baidu nog steeds last van?
Zoja, van waar komen de requests dan? Allemaal 1 IP? Of random?
En aan welke snelheid komen ze binnen?

Zelf hebben we ook een site draaien waarop Baidu nogal agressief spidert, maar dat gaat dan eerder over ongeveer 1 req/s van de Baidu spider. Al hebben we ook eens gehad dat Baidu even lekker los ging, maar na 2 dagen was dat weer over. Google bot spidert ongeveer 8x minder dan Baidu.
Verder heb ik ook eens onze eigen url ingetikt in Baidu en we stonden dan nog zelfs niet bovenaan in de resultaten
Hier ging Baidu even los voor bijna 2 dagen.
De load die er voor de 7e te zien is, is ook bijna uitsluitend afkomstig van Baidu.


Gezien je beperkte geheugen zou ik proberen om het maximum aantal MySQL en Apache2 childs te gaan beperken. Je kan daarmee natuurlijk wel minder requests tegelijk serveren, vraag is hoeveel je er moet kunnen afhandelen per seconde natuurlijk.
Ik zou ook het geheugengebruik van APC en memcached proberen te verminderen zodat je meer ruimte laat in het geheugen.
Eventueel niet alle PHP files in APC gaan steken, maar eerder de meest gebruikte zodat je toekomt met minder memory(40MB bijv.), consequentie is natuurlijk iets meer CPU use.
Of APC naar de disk laten cachen ipv naar het memory (minder snel natuurlijk).
Is memcached strikt nodig? APC kan ook 'user items' cachen...

Hoe staat je keepalive geconfigureerd?
Hoe lang duurt het gemiddeld om de meest opgevraagde pagina's binnen te krijgen?
En hoeveel requests zijn er nodig om de meest opgevraagde pagina's binnen te krijgen?

Eventueel proberen om te vertrekken van een minimal install (Ubuntu bijv?) zodat er om te beginnen alleen draait wat nodig is en je ook alleen extra toevoegt wat nodig is?

[ Voor 8% gewijzigd door Dikke Foaf op 04-01-2012 02:35 ]

8088 schreef op zondag 01 januari 2012 @ 21:42:
[...]

Voor een niet al te druk vBulletin forum is 512MB meer dan toereikend. Het moet alleen wel slim benut worden. Het geheugen uitbreiden is slechts symptoombestrijding en nodeloze geldverspilling als er niet eerst naar andere (voor de hand liggende) opties gekeken wordt.

Het kan meer dan toereikend zijn, maar niet met alle bovengenoemde software pakketten erbij die allemaal een deel van het geheugen opeisen.

Dan zal je een aantal consessies moeten doen wat me niet zinnig lijkt. De TS heeft er (zo te zien) wel plezier in om z'n server te tweaken en met nieuwe software te spelen, dan heb je gewoon meer geheugen nodig.

Juist als je wat wilt tweaken kun je meer met minder geheugen. Er zijn voldoende tips gegeven die sowieso geheugengebruik wat inperken, maar we moeten het doen met een screenshotje van top en helaas blijft een reactie van TS vooralsnog uit...