Mnja, načeloma je fajn če dela brez uporabe swapa. Uporaben je pa v primeru, da se ti začnejo dogajat štale in programje začne na splošno žret preveč spomina. Če imaš swap, ti pač najprej strežnik začne počas delat in imaš še nekoliko maneverskega prostora/časa (sicer z odzivnimi časi nekje v večnosti, ampak vseeno).

Če pa swapa nimaš, ti pa ob pomanjkanju spomina kernel začne pobijati "naključne" procese, in si hiter v štali če ti recimo slučajno ubije ssh daemona...

Vem da je že stara tema, ampak: kako so vam pa vdrli v sistem?

Podatki izpisa te skripte so sami po sebi skoraj neuporabni, ker:

- kateri hardware imaš, lahko vidiš v konzoli in stvar se sama od sebe ne spreminja

- indikatorji stanja sistema ti ne dajejo vpogleda v njihove časovne fluktuacije

Torej s to skripto lahko ugotiviš, da nekaj ne deluje prav, če recimo opaziš uporabo swapa nad 50%, ne boš pa ugotivil, da tvoja težava ne leži tam, ker se je lahko ta uporaba swapa akumulirala preko dveh mesecev, ko izpisa skripte nisi spremljal (nedejavni programi, etc), problem neodzivnosti sistema pa ti dejansko zakuha packet loss na mrežni povezavi.

Alternative:

- collectd

- symon

- ganglia (remote/distributed)

- snmpd (remote)

- cacti/zenoss/opennms (remote)

PS: Bl4ckb1rd ima point.

Mogoce "doesn't" ?

PHP ne podpira multithreading programiranja. Najbols kar lahko nardis je simulacija le-tega z uporabo pcntl-ja. Ampak to kreira povsem nove procese, ki imajo edino zvezo s parentom, da ko umrejo, sistem pošlje SIGCHLD parentu in le-ta lahko prebere exit status umrlega childa. Boš moral pa sam spedenati IPC za vračanje rezultatov itd.

Še mal informacij tukej:

http://phplens.com/phpeverywhere/?q=node/view/254

Ena stvarca, ki sem jo jaz naredil z uporabo pcntlja (standalone application server in php) je pa tukaj, če rabiš primere uporabe in IPCja:

http://github.com/bostjan/PHP-application-server

Te keep-alive nastavitve je priporočljivo držati karseda na minimumu. 2 ali še bolje 1 sekunda. Ker za glavnino uporabnikov je povprečna stran v tem časovnem okviru poservirana. Če ima pa uporabnik počasno povezavo, je pa itak počasno vseskupaj.

Če stran vsebuje vsebine "velikih" razsežnosti (embeded video ipd.) za to ne rabiš povečevati keepalive timeouta, ker to shendla navadna TCP povezava povsem OK.

Edina uporabna vrednost KeepAlive-a je v tem, da lahko omogoči hipno prikazovanje strani. Torej, vneseš URI in pritisneš enter in BAM. Če se to ne zgodi v eni sekundi, po nekaterih raziskavah uporabnik že zazna stran kot počasno. KeepAlive torej omogoča, da se množica majhnih datotek prenese hitreje (prenos v kompletu, kjer je TCP handshake nezanemarljivi del komunikacije). Govorimo o razredu nekaj 10 do nekaj 100 datotek(ic). Z ozirom na zgoraj povedano je uporaba KeepAlive-a za optimizacijo page-loada iz 5-ih na 4,5 sekunde precej brezpredmetna. Pozna se, če ga recimo s 3 sekund spraviš pod 1. Torej KeepAliveTimeout=1 v takem primeru povsem zadošča.

Zakaj še obdržati KeepAlive timeout na minimumu? Ker si na kakem "omejenem" VPSju (omejenem v smislu resursov) na tak način lahko ustvariš AutoDOS attack (če se smem poslužiti takega poimenovanja, analogija je avtogol). Dovolj hkratnih uporabnikov in majhna motnja v delovanju omrežja, ki povzroča določen delay na povezavah, vse to v kombinaciji z rahlo prevelikim KeepAlive timeoutom da rezultat, da ti Apache naspawna toliko procesov, da ti požrejo ves razpoložljivi RAM. V tem primeru ti pa Kernel začne na random pobijat procese, da pridobi malce RAMa nazaj.