Jump to content

diarex

Members
  • Content Count

    60
  • Joined

  • Last visited

  1. Salve, ho la necessità di spostare i siti sulla mia VPS verso hosting condiviso attivando un diverso piano per ciascuno. Lo spazio richiesto è mediamente inferiore al gigabyte. Vista il notevole numero di immagini presenti in ciascun sito non esiste altra soluzione che prelevare quest'ultime tramite uno script che faccia uso di wget oppure spostarle in blocco come TAR per poi scompattarle direttamente a destinazione. E' necessario quindi per me avere a disposizione una shell, cosa mi rendo conto essere poco comune. Le caratteristiche quindi sono: LAMP libredie GD mod_rewrite shell tagli di spazio: 500MB, 1GB, 3GB cron gradito ma non indispensabile Sapete consigliarmi qualcosa?
  2. Rieccomi dopo un anno. Ho una VPS Professional su Aruba con Plesk 8.3.0 su cui sono attivi diversi domini, alcuni fanno uso del server mail della VPS, altri usano i server Aruba. Da un paio di giorni i siti web non riescono ad inviare email verso i domini in hosting nella VPS: Residence Il Baglio - Contatti questa pagina invia una email ad un indirizzo ...@hotmail.it e ...@dominio_su_vps.com, la seconda email non arriva. Anche provando via telnet il risultato non cambia: telnet 95.110.134.216 25 Trying 95.110.134.216... Connected to 95.110.134.216. Escape character is '^]'. 220 areamoto17.com AUTH LOGIN 334 .... ******* 334 .... ******* 235 go ahead mail from: ....@hotmail.it 250 ok rcpt to: ...@dominio_su_vps.com 250 ok data 354 go ahead subject: test telnet prova telnet . 250 ok 1340021639 qp 29918 Il dominio in questione usa Aruba per la posta, in Plesk ho quindi disabilitato il server mail per lui. Tutto ha sempre funzionato, cosa potrebbe essersi corrotto? Quasi dimenticavo, l'errore nel log è il bellissimo "Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)"
  3. diarex

    email verso Libero

    Visto che qualcuno mi ha scritto in privato vorrei aggiungere alcuni dettagli. Ci vogliono 3-4 giorni per avere il PTR propagato dopo che si è fatta richiesta. Per VPS Aruba Dopo che il PTR è propagato le email in coda non partono immediatamente. Qmail le tiene in coda alcuni giorni prima di inviarle nuovamente. Per inviarle tutte usa dalla shell: kill -ALRM `ps ax | grep qmail-send | grep -v grep | awk '{print $1}'` Quindi per vedere cosa accade: tail -f /usr/local/psa/var/log/maillog
  4. Configurare una VPS da soli si può? Io dico di SI, qui l'opinione comune è NO. Ho impiegato oltre due mesi, quindi se non hai mai aperto una shell linux forse vale la pena spendere 200 € per fartela configurare da qualcuno. Premature end of script headers: index.php Eccolo qui, niente di più generico come errore. Le cause: formato dei file non linux (\r\n vs. \n) linee vuote alla fine dei file in Perl inizio output script in maniera errata eccessivo consumo di Ram e CPU (RLimitCPU e RLimitMEM) errata configurazione di SuExec (vedi i log relativi) Quasi tutte queste cause comportano l'errore in maniera permanente, non occasionale. Nel caso in cui l'errore non è continuo ma a tratti le cause potrebbero essere: query al DB lente esaurimento di memoria (azioni pianificate pesanti) CPU troppo carica (azioni pianificate pesanti) raggiungimento dei limiti imposti dalla virtualizzazione tramite Virtuozzo (vedi gli Alerts) E' indispensabile dotarsi di un tool di monitoraggio. FlameNetwork mi ha consigliato Munin. Va installato e configurato a dovere (Apache e MySQL sono un po' laboriosi ma ci solo tantissime guide al riguardo). Personalmente ho verificato che in corrispondenza del "Premature end of script headers" avevo un picco nei processi del MySQL, ho quindi spostato i DB fuori dalla VPS per individuare causa / effetto e purtroppo non era il DB. Posso suggerirvi: https://github.com/rackerhacker/MySQLTuner-perl per verificare l'eventuale presenza di configurazioni non adatte del database che possono far morire gli script. Ok, se fin qui ci siamo ed ancora il problema rimane c'è da chiedersi se Apache sia configurato a dovere (non bisognava chiederselo all'inizio?). Nel mio caso la risposta era no. Si apre: vi /etc/httpd/conf/httpd.conf ed invece di cominciare a toccare cose a caso (come ho fatto un po' io) bisogna individuare tutti i file di configurazione caricati a seguire. Nel mio caso, CentOS 5 + Plesk 8.3, la riga dice: Include conf.d/*.conf Una cartella che già dovreste conoscere. Il mio Apache gira come PreFork, per capirlo basta fare: > httpd -V | grep MPM Server MPM: Prefork -D APACHE_MPM_DIR="server/mpm/prefork" Che sia PreFork, Worker o altro bisogna in ogni caso individuare l'ultimo file di configurazione caricato contenente: <IfModule prefork.c> ... </IfModule> <IfModule worker.c> ... </IfModule> Nel mio caso era /etc/httpd/conf.d/swtune.conf . Tenete presente che i file vengono caricati in ordine alfabetico. Bene, individuato il file responsabile della configurazione definitiva del vostro modulo si può cominciare ad operare tenendo sempre sottocchio Munin: più server si attivano più RAM si usa i "busy server" non devono mai raggiungere il totale dei server Eccola qui, una causa di Premature end of script headers che non ho trovato indicata da nessuna parte. Non fornisco alcuna indicazione sui valori poichè dipendono da RAM, numero vhost, traffico...
  5. Ho attivato la cache nel db ma nulla. Ho sposato il db all'esterno della VPS ma niente. Sono andato a caccia di redirect ricorsive ma niente. Ho creato un log a livello di applicazione ed effettivamente lo script php parte ma non termina. Ho anche stressato il server con tantissime richieste simultanee senza mai aver crolli o problemi di memoria. Perché invece in momenti di traffico normale in processi cominciano a morire?
  6. Ciao, osserviamo il buchetto in Apache process: Munin :: localhost :: localhost In contemporanea ho questo: - numerosi processi che cadono [Wed May 04 22:21:17 2011] [error] [client 67.195.37.91] Premature end of script headers: index.php [Wed May 04 22:21:23 2011] [notice] mod_fcgid: process .....index.php(26024) exit(communication error), get stop signal 9 I siti non rispondono e, forse, danno "Internal Server Error". - picco dei thread MySQL - picco nelle connessioni stabilite - picco nel numero dei thread e nei processi - picco nel carico medio - nessun problema di query lente, memoria, banda, disco, log message e secure, azione pianificata in azione, nessun Alert da Virtuozzo - nessuna attività particolare nei siti, o meglio le pagine richieste al momento sono sempre differenti La fase in cui ho il problema dura pochi minuti, l'ipotesi è che il picco nei processi sia dovuto al fatto che questi come nascono muoiono. Analisi corretta? Dopo che cade il primo processo php-fcgi cadono tutti gli altri. Dopo pochi minuti tutto torna alla normalità. L'errore indicato nei log è generico e non rientro in nessuna casistica (visionati a fondo i siti Apache, Plesk e centinaia di forum). Ma che succede? Perchè caduto uno cadono gli altri? E perchè tutto si normalizza poco dopo? Cosa diavolo viene a mancare? E, soprattutto, cosa ancora dovrei monitorare?
  7. diarex

    Aiuto configurazione VPS

    Non da qui, su un altro ho fatto richiesta esplicita. Si va dalle 160 € per risolvere a 20 €/ora (pacchetti da 600 ore????). Grazie a FlameNetwork. Mi disse che se volevo risolvere avrei dovuto andare in fondo (ma anche che non ne sarei stato capace). Ho passato 2 giorni ad installare Munin e plugin, esaminare i dati e a modificare la configurazione di conseguenza. Al terzo ho supposto un problema di memoria e sul forum Plesk ho trovato la soluzione. Mi fu detto "dipende da come configuri mod_fcgi" quando chiedevo se un Internal Server Error ogni tanto era inevitabile. In cima a questo 3d c'era la mia conf che chiaramente impediva ai processi di terminare prima che esplodesse il tutto. Spero solo che regga 24 ore...
  8. diarex

    Aiuto configurazione VPS

    Mi è arrivata una email: "il problema si risolve in mezza giornata soli 160€ fattura esclusa". Cmq non per cantar vittoria ma forse era un problema di memoria dovuto a processi fastcgi che non morivano mai. Ho aggiunto la direttiva: DefaultMinClassProcessCount 0 ed ora il tempo di vita viene rispettato, i processi muoiono come le mosche, la memoria occupata non sale costantemente. Chissà se sono riuscito a risparmiare 160€.
  9. Ciao, ho installato il plug-in multimemory per Munin. Dopo il riavvio del server httpd è passato da 912MB a 85MB: top invece, dopo un iniziale svuotamento di memoria, è tornato ad indicare i soliti 70MB liberi. Ma questo plugin è affidabile?
  10. diarex

    Aiuto configurazione VPS

    Ok, ma ci fosse stato uno che abbia scritto a tot euro te la sistemo io. Non si trova un sistemista nemmeno a pagarlo?
  11. diarex

    Aiuto configurazione VPS

    No aspetta, quando si dice che le VPS sono già pronte non è vero. Ne ho provate 2 e la creazione dei file non funzionava in entrambe: <? $dirName = date( "ymdHis", time() ); echo "Cartella destinazione: ".$dirName."<br/>"; if( ! mkdir( $dirName ) ) { echo "Impossibile creare la cartella"; exit; } $fp = fopen ( $dirName. "/index.html", "w" ); $success = fwrite( $fp, "ciao" ); fclose( $fp ); if( ! $success ) echo "impossibile creare il file"; ?> Per ciò che riguarda i verbali non capisco e non importa. Sono qui per capire se potete darmi o no una mano al seguente problema: dopo un po' dal riavvio del server i processi di Apache non occupano CPU ed i siti non rispondono. Questo è quello che mi interessa. Ho postato configurazioni, log, top, munim, infophp, statistiche... se sapessi cosa cercare sarebbe più semplice
  12. diarex

    Aiuto configurazione VPS

    E' tutta una questione di costi chiaro. Se il servizio di hosting mi fruttasse 100 € al mese avrei preso un servizio da 100 € al mese. Siccome sono a 36 €/mese quello che ho è il max che posso permettermi. Dietro consiglio di FlameNEtwork ho appena finito di installare Munin: Munin :: overview ora blocco i riavvii del server ogni 5 minuti e vediamo dove sta il problema. :icon_dho:
  13. diarex

    Munin??

    E già... manco yum c'era installato nella mia VPS. Per installare yum ho usato i seguenti pacchetti, magari in futuro potrà servire a qualcuno: wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-urlgrabber-3.1.0-6.el5.noarch.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/m2crypto-0.16-6.el5.8.i386.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-elementtree-1.2.6-5.i386.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-sqlite-1.1.7-1.2.1.i386.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/sqlite-devel-3.3.6-5.i386.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/python-iniparse-0.2.3-4.el5.noarch.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/sqlite-3.3.6-5.i386.rpm rpm -Uvh *rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/yum-fastestmirror-1.1.16-14.el5.centos.1.noarch.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/yum-metadata-parser-1.1.2-3.el5.centos.i386.rpm wget http://mirror.centos.org/centos-5/5/os/i386/CentOS/yum-3.2.22-33.el5.centos.noarch.rpm rpm -Uvh yum* Bene, sul forum ho trovato citata una guida all'uso di Munin su HT ma non la trovo, me ne consigliate una?
  14. diarex

    Aiuto configurazione VPS

    Una cosa è funzionare male un'altra è non funzionare proprio. Andrà bene per un solo sito statico, ma appena ci metti uno script php per l'upload di un file non funziona per i permessi delle cartelle. Poi le sessioni.... Ma poi non è possibile preparare le VPS con configurazioni simili a quelle degli hosting condivisi? Che male ci sarebbe se permessi dei file e sessioni fossero già funzionanti? Se poi mi viene dato Plesk per 30 domini perché al nono il prefork deve andare in errore? Una cosa è dar la possibilità di fare tutto, un'altra è costringere a far tutto.
  15. diarex

    Aiuto configurazione VPS

    E' chiaro che i test prima di entrare in produzione non sono stati adeguati ed ora mi ritrovo così. Però queste VPS vengono vendute con la promessa di assistenza che poi non c'è. Vengono dichiarate già pronte mentre non lo sono. E quando ti dicono che puoi settare il server come vuoi è un sogno che si avvera. Quante volte ho dovuto rinunciare ad una progress bar per gli upload in Flash o in Perl a causa della configurazione di Apache! Pensavo di limitarmi a questo perché avrei trovato il resto a posto. Ma quando mai. Al nono VHost la situazione è crollata. Il deafault per MaxRequestPerChild è 4000, tuttavia solo scendendo a 100 ho ottenuto una situazione stabile. Le prestazioni sono l'ultimo dei mie pensieri al momento, mi basta la continuità. E sono costretto ancora a scendere nei meandri della configurazione perché vedere i siti che non rispondono ed i processi che non impegnano CPU mi infastidisce parecchio. Domani potrò provare il tool che mi consigli e, per buona pace dei miei clienti, farò altri test. Grazie.
×