AIUTO !!! dcachesize mi blocca !!

[kitconsulting]

Salve a tutti,

mi presento essendo nuovo e spero non fare troppe gaffe !!

Ho una VPS su un server linux centos con plesk 9.2.2 .....

Da una settimana circa il parametro dcachesize mi blocca con regoarita e letteralmente il server tant'è che devo riavviare il container spesso e malvolentieri !!

Vi dò qualche caratteristica sperando che qualche anima santa mi possa aiutare ...

Parallels Plesk Panel version 9.2.2
Operating systemLinux 2.6.18-028stab062.3
CPUGenuineIntel, Intel(R) Xeon(R)CPU E5420 @ 2.50GHz
Average load0.08; 0.06; 0.07
2 Gb di memoria

Parameter Current UseSoft Limit Hard Limit
dcachesize 4,489,709 5,058,904 5,576,560

Questo valore si incrementa tal volte fino al puto di "inchiodarmi" completamente il server ....

Aiutatemi vi prego .......

Grazie mille

[Ste]

Ciao, basta leggere in giro, è un parametro di virtuozzo, collegato agli inodes:

dcachesize

dcachesize: the total size of dentry and inode structures locked in memory.
The dcachesize parameter controls filesystem-related caches, such as directory entry (dentry) and inode caches. The value accounted into the dcachesize parameter is also included into kmemsize. dcachesize exists as a separate parameter to impose a limit allowing file operations to sense memory shortage and return an error to applications, protecting applications from memory shortages during critical operations that shouldn't fail.
The configuration of this parameter should have a gap between the barrier and the limit (about 10%, as illustrated in Appendix B). The configuration of this parameter doesn't affect security and stability of the whole system or isolation between Containers. Its configuration affects functionality and resource shortage reaction of applications in the given Container only.

Sembra che sia principalmente un problema legato a MySQL, almeno leggendo il forum di spry: Overly large dcachesize? Tuning tip for my.cnf - Spry Forums
Prima di tutto però bisognerebbe capire quando lo fa e che uso ne fai del server

[kitconsulting]

Grazie per la tua risposta ....

allora il server come detto è un VPS linux con virtuozzo presso un provider AZIENDE Italia Srl.
Su questo server virtuale girano circa 70 domini e 11 DB !!

Non mi ha mai dato problemi fino all'aggiornamento con plesk 9.2.2.

Mi chiedevo ... accedendo al server in ssh sarebbe possibile aumentare questo valore ??

Grazie ancora

[Ste]

Il server è gestito da Aziende Italia? Ovvero hai un contratto managed, se la risposta è si, apri un ticket alla loro assistenza e risolveranno i loro sistemisti. Altrimenti si, devi lavorare da SSH, andando a vedere cosa non va, ma se sei poco pratico potrebbe essere dura

[Uno]

No dcachesize può essere modificato solo dal sysadmin del server che ospita i vps.
Potresti al massimo intervenire (se è possibile) sul problema che genera troppi inode in memoria.

[posmag]

allora il server come detto è un VPS linux con virtuozzo presso un provider AZIENDE Italia Srl.
Su questo server virtuale girano circa 70 domini e 11 DB !!

Leggo il tuo messaggio e a questo punto temo che ci siano problemi con i VPS di Aziende Italia.
Il nostro dovrebbe avere 1 GB di RAM dedicata (2 GB massimo), 10% CPU dedicata (doppio Xeon quad-core), massimo 10 VPS per server.
Ci ospitiamo una decina di siti a basso traffico, tipo 4 GB/mese totali. Ognuno con CMS con tutte le cache attive, memory_limit settato a 32 MB.
Risultato: VPS sempre vicino alle soglie di tolleranza, problemi anche di notte. Qualsiasi attività lanci (un cron, una newsletter) i parametri kmemsize e oomguarpages finisco in zona gialla/rossa, perché partono già vicini. La sensazione è che sia tutto molto 'tirato'.
Mentre aggiorni le pagine di un sito, il VPS ti cede sotto i piedi: pagine non trovate, database irraggiungibile etc. Cose da hosting a 20 euro l'anno!
Virtuozzo inutilizzabile, i clienti non riescono a lavorare, noi ci becchiamo le proteste.
L'assistenza via mail non fa un passo, lasciano lì il disservizio e ti dicono di guardare i log. Al telefono ho avuto la sensazione, purtroppo, di saperne più del tecnico.
Noi siamo clienti di questo fornitore da tempo, prima era meglio, mi chiedo cosa succede e mi interesserebbe sentire altri.

[Uno]

Ti faccio le domande di Ste

Il server è gestito da Aziende Italia? Ovvero hai un contratto managed, se la risposta è si, apri un ticket alla loro assistenza e risolveranno i loro sistemisti. Altrimenti si, devi lavorare

(ho tagliato un pezzo così rende di più, anche se sadicamente avrei voluto sottolineare "devi lavorare" )

Se non è managed puoi provare a vedere i log ed in caso aprire altro 3d per chiedere consigli

[posmag]

Se non è managed puoi provare a vedere i log ed in caso aprire altro 3d per chiedere consigli

Ti ringrazio per l'interessamento, è un server gestito.
Secondo me un VPS non gestito dal fornitore non ha senso, proprio da un punto di vista logico. Comunque il nostro è gestito.
Con l'assistenza ho già lavorato al problema, l'impressione è quella riportata sopra. Potrei citarti alcune risposte deprimenti, ma non mi interessa polemizzare.
Dopo tanti anni nel settore riconosco una situazione ottimizzabile da una senza speranza. Qui abbiamo siti semplici e poco traffico su una macchina con (teoricamente) 1-2 GB di RAM e doppia CPU Xeon.
Configuriamo tutto alla perfezione? Passaremo da carico leggero a leggerissimo.
Per farti un esempio, abbiamo già spostato di notte i processi (cron) che secondo l'assistenza esaurivano le risorse.
Risultato: tutto come prima e VPS sempre al limite.
Se conosci Plesk/Virtuozzo, puoi darmi info generiche sui processi kmemsize e oomguarpages? Cosa li fa esplodere?
Magari c'è qualcosa che mi è sfuggito, come vedi mi devo fare assistenza da solo.

[Antonio]

Ti ringrazio per l'interessamento, è un server gestito.
Secondo me un VPS non gestito dal fornitore non ha senso, proprio da un punto di vista logico. Comunque il nostro è gestito.

E perché mai? Se io so amministrarmelo e so dove andare a mettere le mani, perché dovrei pagare per un servizio che non uso?

Comunque, se anche il fornitore ti dice di guardare i log del server, significa che il servizio non è managed, ma devi capire tu cosa da problemi andandoti a saturare le risorse a disposizione.

Nel caso in cui fosse stato managed, avrebbe dovuto provvedere il gestore a dirvi almeno cosa è che vi fa andare in sofferenza il VPS.

Se conosci Plesk/Virtuozzo, puoi darmi info generiche sui processi kmemsize e oomguarpages? Cosa li fa esplodere?
Magari c'è qualcosa che mi è sfuggito, come vedi mi devo fare assistenza da solo.

Quei parametri sono relativi alla ram, quindi se usi più ram di quella garantita (bada bene, GARANTITA non quella massima usabile) virtuozzo ti avverte.
Se consumi più ram di quella garantita, il sistema di virtualizzazione di virtuozzo, se si trova a corto di ram sul nodo, fa una cosa molto carina: ti zappa tutti i processi (in esecuzione e nuovi) fino a costringere la tua vps ad usare solo la ram garantita (con grande gioia di mysql & Co.).

Posta qui il contenuto del file: /proc/user_beancounters , così vediamo quali sono i parametri della tua VPS con precisione.

[posmag]

E perché mai? Se io so amministrarmelo e so dove andare a mettere le mani, perché dovrei pagare per un servizio che non uso?

Nel senso che in un VPS parte della struttura software della macchina rimane per forza di cose fuori dal tuo controllo. Caricarti la gestione/risoluzione problemi di un server (virtuale) dove ad es. non puoi toccare php.ini, my.cnf etc lo trovo fonte di gran perdite di tempo. A questo punto fai tutto tu provider, che hai la situazione reale sotto controllo. Comunque è solo la mia opinione, ci mancherebbe.

Se consumi più ram di quella garantita, il sistema di virtualizzazione di virtuozzo, se si trova a corto di ram sul nodo, fa una cosa molto carina: ti zappa tutti i processi (in esecuzione e nuovi) fino a costringere la tua vps ad usare solo la ram garantita (con grande gioia di mysql & Co.).

Accidenti! Capisco perché molti ne parlano male. Mi sembra un metodo che può funzionare se gestito da me per i miei servizi, ma che ai clienti darà solo problemi.

Posta qui il contenuto del file: /proc/user_beancounters , così vediamo quali sono i parametri della tua VPS con precisione.

Ebbene, è vuoto. Proprio dimensione zero byte...

[Antonio]

Nel senso che in un VPS parte della struttura software della macchina rimane per forza di cose fuori dal tuo controllo. Caricarti la gestione/risoluzione problemi di un server (virtuale) dove ad es. non puoi toccare php.ini, my.cnf etc lo trovo fonte di gran perdite di tempo. A questo punto fai tutto tu provider, che hai la situazione reale sotto controllo. Comunque è solo la mia opinione, ci mancherebbe.

Se hai accesso root al vps puoi modificarti come più ti piacciono tutti i file di configurazione, come puoi anche installare altri software.

Accidenti! Capisco perché molti ne parlano male. Mi sembra un metodo che può funzionare se gestito da me per i miei servizi, ma che ai clienti darà solo problemi.

Diciamo che molto dipende dal provider e da come configura virtuozzo; fermo restando che sarebbe meglio usare, secondo me, vps xen/vmware dove sai con precisione quali sono le risorse che hai a disposizione.

Ebbene, è vuoto. Proprio dimensione zero byte...

Niente paura, usano la nuova interfaccia, quindi il file che interessa è /proc/bc/resources

[posmag]

Diciamo che molto dipende dal provider e da come configura virtuozzo; fermo restando che sarebbe meglio usare, secondo me, vps xen/vmware dove sai con precisione quali sono le risorse che hai a disposizione.

Già, confermo. Senza nulla togliere alla Parallels, dietro Xen c'è una comunità enorme e dietro Vmware il principale fornitore mondiale di storage. Se ci devi lavorare meglio andare sul sicuro.

Niente paura, usano la nuova interfaccia, quindi il file che interessa è /proc/bc/resources

...Che purtroppo non c'è.
Eccoti il contenuto della cartella /proc, purtroppo l'interfaccia del file manager non mi consente di fare ricerce e l'accesso SSH, nominalmente 'di root', semplicemente non va.
Sottodirectory:
fs
net
self
sys
sysvipc
vz

File, tutti zero byte:
cmdline
cpuinfo
devices
filesystems
kmsg
loadavg
locks
meminfo
modules
mounts
stat
swaps
uptime
user_beancounters
version
vmstat

Nel preciso istante in cui scriviamo, il VPS con doppio quad-core e 1-2 GB di RAM è al collasso senza che nessuno stia facendo NULLA!
Anche gli uffici dei clienti ormai sono chiusi, e non c'è nessuna newsletter perché i cron di Drupal (che ben conoscete su Hostingtalk no? :-) ) girano di notte.
Ragazzi che schifo.
Spero se non altro che la discussione metta in guardia chi usa questo sito per decidere i propri acquisti.

[posmag]

Dimenticavo... Veramente grazie per l'aiuto che mi stai dando, per di più a quest'ora.

[Antonio]

Già, confermo. Senza nulla togliere alla Parallels, dietro Xen c'è una comunità enorme e dietro Vmware il principale fornitore mondiale di storage. Se ci devi lavorare meglio andare sul sicuro.

Più che altro perché funzionano in maniera diversa: non creano container come virtuozzo, ma virtualizzano tutto.

...Che purtroppo non c'è.
Eccoti il contenuto della cartella /proc, purtroppo l'interfaccia del file manager non mi consente di fare ricerce e l'accesso SSH, nominalmente 'di root', semplicemente non va.
Sottodirectory:
fs
net
self
sys
sysvipc
vz

File, tutti zero byte:
cmdline
cpuinfo
devices
filesystems
kmsg
loadavg
locks
meminfo
modules
mounts
stat
swaps
uptime
user_beancounters
version
vmstat

Ma anche facendo un cat non vedi niente?

cat /proc/user_beancounters

/proc è un filesystem virtuale è normale che i file siano 0k

[posmag]

Ma anche facendo un cat non vedi niente?

Purtroppo la console SSH di Virtuozzo non va, col Telnet classico non riesco ad accedere.
Immagino che abbiano cambiato la posizione predefinita del file /proc/bc/resources, cercando su Google vedo che si può fare.
Stavo scrivendo apro un ticket ma mi è venuto da ridere, immagino la risposta: "Può vedere il file collegandosi via SSH" (che non va).
Mi puoi suggerire qualche altra posizione classica per il file /proc/bc/resources? Oppure dove sta il suo backup automatico, se esiste?
Grazie!