Newsgroup: it.comp.os.linux.sys
Titolo: Apache e molti file include

Uso Apache 2.2.3 su Debian Etch. Sistema di sviluppo. Genero N VirtualHost 
per M persone che lavorano col sistema di sviluppo. Quindi per ogni persona 
ho un file .conf in sites-available e symlink in sites-enabled.
Quando N > 30, Apache diventa scemo. Fai il restart, risponde a un po' di 
connessioni e poi comincia a dare problemi strani: pagine in bianco, non può 
fare require_once di PHP. 
Sembra un problema di limits, ma in /etc/security/limits.conf ho alzato il 
limite per www-data a 20000 file aperti contemporantemente.
La cosa strana è che se genero un .conf unico (cat /etc/apache2/sites-
enabled/* >> /etc/apache2/sites-enabled/file-unico.conf ) funziona senza 
problemi. Basta anche cancellare un solo dei 30 .conf e funziona.
Qualcuno ha mai avuto esperienze simili o qualche idea al riguardo?
-- 
Vide

 il limite per www-data a 20000 file aperti contemporantemente.
Non penso sia un problema di limits.
Io su un server ho 195 virtualhosts attivi e limits (sia di security che 
di apache) di default.
Puoi postare uno di quei .conf per vedere cosa ci combini? :)
Bye.


    ServerName user.domain.tld
    DocumentRoot /home/user/www.domain.tld
    php_value session.cookie_domain "domain.tld"
    php_value auto_prepend_file "/home/user/configs/prepend.inc"
    php_value auto_append_file "/home/user/configs/append.inc"
    Options Indexes +FollowSymLinks
    Alias /css_new/ /home/user/common/css/
    Alias /js_new/ /home/user/common/js/
    Alias /addons/ /home/user/addons/    
    Alias /js_gen/ /var/www/js_gen/
    ErrorLog /var/log/apache2/user-domain.tld-error.log
    CustomLog /var/log/apache2/user-domain.tld-access.log combined
     <Directory "/home/user/www.domain.tld/directory1">
      RewriteEngine on
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteRule ^(.*)$ /directory1/ModRewrite.php [L,QSA]
    </Directory>
    <Directory "/home/user/www.domain.tld/directory2">
      RewriteEngine on
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteRule ^(.*)$ /directory2/ModRewrite.php [L,QSA]
    </Directory>
    <Directory "/home/user/www.domain.tld/directory3">
      RewriteEngine On
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteRule ^(.*)$ /directory3/index.php [L,QSA]
    </Directory>
    <Directory "/home/user/www.domain.tld/directory4">
      RewriteEngine On
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteRule ^(.*)$ /directory4/index.php [L,QSA]
    </Directory>
    <Directory "/home/user/www.domain.tld/directory5">
      RewriteEngine On
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteRule ^(.*)$ /directory5/index.php [L,QSA]
    </Directory>
    <Directory "/home/user/www.domain.tld/directory6">
      RewriteEngine On
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteRule ^(.*)$ /directory6/index.php [L,QSA]
    </Directory>   
</VirtualHost>         
ripetuto per 540 (sì, cinquecentoquaranta) volte diverse (cambiano nomi, 
directory ecc).
Più di queste 540 volte, salta tutto per aria :)
Ah, l'IP non cambia *mai*
-- 
Vide

 *mai*
Hey, hey! Erano 30, ora sono 540! ;)
Mi e` successo che Apache si "incastrasse" dando pagine bianche, ma era 
una configurazione diversa, e li` il problema era forse dovuto a jboss. 
Quando c'era traffico intenso per un po', apache andava in coma, e dovevo 
riavviarlo. Era una RHEL 3, se non ricordo male.
Hai provato ad aumentare i limiti dentro apache2.conf (MaxClients e 
simili)?
Bye.

 simili)?
No, però non penso abbia a che fare con la cosa.
-- 
Vide

 un bel po' di require_once.
Io una volta ho avuto un problema simile al tuo, ma avevo 1024 vhost (non
casuale) e raggiungevo i limiti di FD per processo Linux (1024). Me ne
accorsi facendo uno strace del processo. Iniziai a togliere quelli nno piu'
attivi e tutto riprese a funzionare.

 piu' attivi e tutto riprese a funzionare.
Bingo! Sono al 100% i file descriptor aperti per i log.
# cat /etc/apache2/sites-enabled/users.conf |grep "Log"|wc -l
1008
e funziona. Se supera 1024, non funziona. In limits.conf, soft e hard li ho 
messi più alti e 
# cat /proc/sys/fs/file-max
371278
ergo sembra essere qualche limitazione dell'Apache2 compilato in Debian.
Una soluzione potrebbe essere quella di inviare i log a un syslog 
(utilizzando logger, come faccio già in produzione)
-- 
Vide

 messi più alti e 
Non servono a niente i limiti del limits.conf. Qui si sta parlando di
file descriptor per processi di Linux, che non e' una cosa tunbabile
lato userland, ma e' una define nel kernel e non va cambiata. Devi
semplicemente usare un tool decente per gestire i log. Prova con
rotatelogs.

 rotatelogs.
Useró syslog-ng o rsyslog (sono curioso di provarlo dopo le ottime 
recensioni di Zipman) + rotate/script manuale (tanto sempre separo in 
directory in base a anno/mese/giorno)
-- 
Vide

 Sì, investigando per bene ieri l'ho visto.
http://httpd.apache.org/docs/2.2/vhosts/fd-limits.html

 
http://httpd.apache.org/docs/2.2/vhosts/fd-limits.html
Appunto :)
Ma a sto punto preferisco usare un server di syslog, tanto c'ho la 
configurazione già fatta per un altro.
Sempre sperando Apache non apra un FD anche se utilizzo logger, perchè 
altrimenti devo fare il log unico come dice nel link.
-- 
Vide

Vide wrote:

sì, ma è abbastanza strano.
il numero max di file per processo (NR_OPEN) nei kernel mediamente moderni è 
di 1024*1024.
prova ad alzare i limiti per tutti gli utenti:
*     -    nofile    20000

 *     -    nofile    20000
I limiti nel limits.conf non sono quelli del FD del kernel.

 I limiti nel limits.conf non sono quelli del FD del kernel.
Comunque tutti i 1000+ FD dei log riconvertiti a logger verso syslog 
remoto... ancora peggio. Faccio restart dell'apache e non risponde a niente, 
generando un bel po' di <defunct> tra l'altro.
Mi rimane solo provare col FD unico e l'etichetta del virtualhost che è. Più 
che altro perchè voglio qualcosa di scalabile, se entra gente nuova o 
aumentano i domini gestiti, il problema si ripresenterá.
-- 
Vide

 I limiti nel limits.conf non sono quelli del FD del kernel.
certamente.
ma a te risulta che il kernel tutt'oggi sia limitato a 1024 fd per processo?

gt ha scritto:

Infatti.
Basta un semplice ulimit -aH per capire da dove viene il limite di 1024
bubbolone:/home/jacopo# ulimit -aH
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 26621
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 26621
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
Ovvero per default ulimit limita a 1024 i file che un utente piò aprire.

 Basta un semplice ulimit -aH per capire da dove viene il limite di 1024
<ironia>
Ed è arrivato lo sveglione.
</ironia>
Tu credi non sia la prima cosa fatta? L'ho anche scritto più di una volta in 
'sto stesso thread.
Questo è l'utente che esegue apache:
$ ulimit -n
10000
ergo NON c'entra con ulimit, come dice giustamente antani.
-- 
Vide

 
Scusa ma quandti fd hai in uso nel sistema quando è attivo apache??

Vide wrote:

il documento che ti ho linkato invece dice proprio che c'entra con ulimit.
solo che non riguarda i limiti dell'utente che esegue apache, ma quelli di 
root.
anch'io, anch'io:
<ironia>
     lì da te chi è che scrive i log di apache?
</ironia>

 root.
root ha 20000, fai tu. 
-- 
Vide

 
e vabbè, un'informazione alla volta.
dire prima che hai alzato limit anche per root? :-)
sarà mica che il package apache2 per debian etch è compilato con questo 
limite?
ma nell'error.log ci sono riferimenti al superamento del numero di file 
descriptor?

 descriptor?
No, nessun log "strano". Comunque il problema è al 100% quello.
-- 
Vide

 No, nessun log "strano". Comunque il problema è al 100% quello.
Se il problema sono i file handle, visto che i FH sono "per process",
allora usa il PHP in cgi.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 allora usa il PHP in cgi.
Sì però questa non è una cosa che possa cambiare dall'oggi al domani.
-- 
Vide