Ik zou aanraden meteen te upgraden naar 2.4.x. Qua performance een stuk beter.
Aanpassen kan in de options.conf en daarna httpd opnieuw compilen met ./build httpd
Afdrukvoorbeeld
Ik zou aanraden meteen te upgraden naar 2.4.x. Qua performance een stuk beter.
Aanpassen kan in de options.conf en daarna httpd opnieuw compilen met ./build httpd
./build apache werkt wat beter, tijd voor koffie denk ik :)
Nou ik ben nu naar de 2.27 maar komende nacht maar naar de 2.4.x.
Bedankt voor de tip
Top, de downtime is iets langer door een rebuild van PHP daarna
Nou daarom doe ik het ook liever in de nacht. Enkel afgelopen nacht lijkt weinig geholpen te hebben naar 2.27
Dat en met 2 dingen tegelijk bezig. Multitasken gaat niet altijd goed ;)Citaat:
Oorspronkelijk geplaatst door Bart L
Daarom moet je het ook in de nacht doen :)
Ter informatie: de sess_ bestanden zijn sessie bestanden voor PHP (session_start()). Niks geks dus.Citaat:
Oorspronkelijk geplaatst door Dutchboy
Tip: server-status is een moment opname. Je kan CSF (http://configserver.com/cp/csf.html) instellen om je server-status te laten sturen als de server belasting hoog is. Dan hoef je niet op server-status te blijven bashen:)
Ook een goeie tip. Ga ik er vannacht gelijk even bij mee proberen te pakken.
Dat "localhost null" zijn gereserveerde processen die staan te wachten om weer aan het werk te gaan, die doen dus feitelijk bijna niets qua belasting.Citaat:
Oorspronkelijk geplaatst door Dutchboy
Dat moet ie ook doen (dat reserveren) om snel nieuwe processen bij te kunnen schakelen als het nodig is.
Als je een tijdje je server-status monitort zul je vermoedelijk toch zien wat het probleem veroorzaakt. Tegenwoordig zijn er bijvoorbeeld nogal wat scrapers die een website van voor tot achter indexeren en downloaden, dat kan beste een pittige belasting zijn voor een shared server, omdat ze het niet pagina voor pagina doen maar gewoon alles tegelijk, verdeeld over meerdere connecties (resulterend in heel veel PID vermeldingen in je status en httpd vermeldingen in je DA).
Als je een bericht krijgt in je DA ticketsysteem (Warning: The system load average is xx.xx) staat er in het bericht zelf trouwens ook vaak al meer informatie over waar dit door veroorzaakt wordt. Als dit door een bepaalde user wordt veroorzaakt staat zijn gebruikersnaam er gewoon bij.
Soms staat er bijvoorbeeld ergens een cronjob affiliate-producten in een shop te importeren wat niet helemaal vlekkeloos gaat, omdat hij bijvoorbeeld staat te wachten op een trage verbinding van de affiliate.
Overigens is het ook best de moeite waard om eens in user-crons te kijken wat er zoal gestart wordt door je klanten. En ook kun je eens kijken wat er zoal aan backups draait op de meest ongelukkige momenten.
Goede tip! /var/log/cron is je vriend.Citaat:
Oorspronkelijk geplaatst door cfmweb
Tasks: 228 total, 3 running, 225 sleeping, 0 stopped, 0 zombie
Cpu(s): 20.7%us, 11.2%sy, 0.0%ni, 49.1%id, 18.7%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 7957156k total, 7810412k used, 146744k free, 16192k buffers
Swap: 16382900k total, 37388k used, 16345512k free, 6574864k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30013 apache 20 0 223m 19m 5212 R 93.4 0.2 0:21.97 httpd
Nu loopt dus de server de load in
Het is duidelijk dat httpd de processor 'tijd' in beslag neemt.
Wat zegt je server-status op dit moment, wie neemt httpd in beslag?
Er staat overal apache bij :S
Euhm, apache is 'eigenaar' van de proces. Maar zie je of een bepaalde URL wordt aangeroepen, of dat een specifiek IP load veroorzaakt?
edit: doe even screenshot van server-status erbij?