Protoze: php, mod_perl (mnoho skriptů, ktere zůstavají po zkompilovaní v paměti) mnoho perlovských modulů (konkrétně 300) a např Geo:IP má včetně svojí databáze 10 MB. Taky jsem měl období, kdy jsem si myslel, že to není možné a snažil jsem se zjistit, kde uniká paměť, ale pak jsem to začal počítat a fakt to nejde o moc srazit.
Rozhodně netvrdím, že to je běžná konfigurace. :)
V pripade mod_perl zkompilovaneho jako modul, a neprilis cistych scriptu memory leak je docela bezna vec. Resenim je staticky vkompilovany mod_perl, a 'use strict;' bez vyjimek.
use strict je jasna vec. Stejne tak plna kvalifikace jmen promennych, protoze vytvareni aliasu je velky zrout pameti.
Neni mi ovsem jasne co mate proti mod_perl jako dynamickemu modulu. Sice to je teoreticky trochu pomalejsi, ale rozdil je IMHO stejny jako kernelovsky modul vs. staticky zakompilovane do jadra. Tj. nestoji to za tu tezsi udrzbu.
No, prave. Pokud mam jadro pro konkretni hw a sw konfiguraci, je vhodne (i z bezpecnostnich duvodu) mit cele jadro staticky, bez podpory pro loadovani modulu. Nebo pokud jadro menim za novejsi casteji nez hw/sw. Mimo distribucni jadra, ktera musi mit sirokou hw kompatibilitu, jadra v systemech jejihz vyuziti je ruznorode, nebo kde se casto meni hardware nema modularni jadro vetsiho smyslu.
Troufam si tvrdit, ze staticky zakompilovany modul vetsi udrzbu neudela, stejne se musi updatovat apache jako takovy a je tedy jedno zda skompiluju apache a modul nebo rovnou apache s modulem uvnitr.
Neni to jedno. Protoze s modulama mi staci udelat 'apt-get upgrade', Kdezto kompilace je kapicku narocnejsi a navic bych sam musel sledovat, jestli se neobjevila nejaka bezpecnostni chyba apod.
A to nedokaze Geo:IP sdilet svoji databazi mezi thready? To musi mit kazdy thread vlastni kopii?
Ono by stacilo to v pameti nasdilet a hned je 1 GB usetren :o)
