Newsgroup: it.comp.os.linux.development
Titolo: La open è troppo lenta!

Ciao a tutti,
vi sottopongo il seguente problema:
recentemente abbiamo notato un degrado delle prestazioni del nostro
applicativo (scritto in c) e dopo alcuni test il collo di bottiglia č
risultato essere una open che viene chiamata, in condizioni di massimo
sforzo anche 30000 volte al minuto per creare un nuovo file, all'inizio il
sistema sembra farcela ma al crescere del numero di files nella directory la
open prende sempre piů tempo per essere eseguita fino ad arrivare ad un
punto di rottura circa 100000 files oltre i quali le prestazioni degradano
troppo con un effetto a valanga che coinvolge code di messaggi che non
vengono svuotate... timer che entrano in ritardo etc...
In prima battuta abbiamo pensato di cambiare le directory in cui questi
files vengono prodotti utilizzandone una nuova per ogni giorno, ma ancora
non va bene il prossimo passo credo sia creare una nuova directory ogni ora
e vedere come va...
Quello che vi chiedo č giusto qualche informazione in piů...
Ho ipotizzato che il maggior tempo preso dalla open č dovuto al fatto che
prima di creare un nuovo file deve verificare se questo esista ed
evidentemente la ricerca all'interno di una directory con 3 milioni di files
tutti con nomi simili non sia un operazione gratuita e che se questa ricerca
venga fatta ad esempio (magari sparo una c....ta enorme!) con tabelle hash
di una certa dimensione e che sopra un certo numero di files vi siano troppe
collisioni che rallentano la open
Magari č possibile effettuare un tuning sul filesystem per velocizzarla?
O esiste magari un modo per creare file senza prima verificare che questo
esista per velocizzare questa operazione?
Aggiungo qualche infotmazione sul sistema:
Red Hat Enterprise 3 Upd 3
File system ext3 disco scsi da 146G
Qualcuno puň darmi qualche delucidazione????

 venga fatta ad esempio (magari sparo una c....ta enorme!) 
invece il problerma č proprio questo, imho.
mi ci sono scontrato anche io, la tecnica delle diverse directory per ogni
ora di esecuzione ,dovrebbe fare al caso tuo

 Qualcuno puň darmi qualche delucidazione????
Se il suggerimento di usare ReiserFS e' efficace spero che tu ce lo dica.
ciao.
Roberto.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 esista per velocizzare questa operazione?
Senza modificare i sorgenti del kernel credo non sia possibile, visto
che e` un'operazione potenzialmente distruttiva in contesti non
controllati.
Bye.
-- 
Alessandro Pellizzari

 File system ext3 disco scsi da 146G
Con ReiserFS invece di ext3 le cose dovrebbero migliorare, ma 100000 
file nella stessa directory rimangono comunque tanti da gestire per 
qualsiasi filesystem. Meglio se suddividi.
-- 
   |   \    \  | ___|_  |_  |  ianezz a casa sua... :-)
   |  _ \  | \ | _|    /   /   Verba volant, scripta
  _|_/  _\_|  _|____|___|___|  manent, data corrupted


Grazie a tutti siete stati chiarissimi, dopo un po di test ho optato per una
divisione in directory su base oraria i tempi della open sono notelvomente
migliorati.
Per quanto ho notato che un ulteriore problema potrebbe essere il numero di
file aperti contemporaneamente in campo si puň arrivare anche a 4000...
Con un numero di file cosě alto quali problemi di efficenza si possono
creare?
Tuttavia visto il tipo di file che scrivo (sono dei file raw con pacchetti
presi dalla rete) l'accesso al filesystem e i tempi di I/O rimangono un
collo di bottiglia ho predisposto una macchina per effettuare un po di test
con altri tipi di file System (reiser ad esempio) visto che dal lato
applicativo mi interessa ottimizzare sopratutto la scrittura su disco
piuttosto che la lettura!

 creare?
Non credo ci siano problemi di prestazioni. Normalmente, su un paio di
server web che gestisco, si puo` arrivare anche a 120.000 file aperti
contemporaneamente (tra pagine, log, pipe, ecc.) e le prestazioni sono
buone.
Non so dirti pero` come si possa comportare un singolo processo con
cosi` tanti file. Il mio carico e` distribuito tra qualche centinaio di
processi (apache, mysql, postgres, ecc.)
Bye.
-- 
Alessandro Pellizzari