Perché PHP si blocca occasionalmente su session_start()

Question

NB Questo è non un duplicato di PHP session_start() causing HTTP requests to hang (e altre domande con nome simile su SO), poiché il mio blocco è occasionale, non permanente.

Utilizzo di Ubuntu 12.04,Magento, PHP-FPM (5.4) e gestore di sessione PHP predefinito (con file su ext4).

inciso (once per month) tutti i processi PHP appendere session_start() (secondo FPM-slow.log):

[24-Sep-2014 11:03:04] [pool www] pid 24259 
script_filename = /data/web/public/index.php 
[0x00007f00b4ec6480] session_start() /data/web/public/includes/src/__default.php:7687 
[0x00007f00b4ec6130] start() /data/web/public/includes/src/__default.php:7730 
[0x00007f00b4ec5fb8] init() /data/web/public/includes/src/__default.php:8086 
[0x00007f00b4ec5e30] init() /data/web/public/includes/src/__default.php:33902 
[0x00007f00b4ec5bd0] __construct() /data/web/public/includes/src/__default.php:23841 
[0x00007f00b4ec5ae8] getModelInstance() /data/web/public/app/Mage.php:463 
[0x00007f00b4ec59c8] getModel() /data/web/public/app/Mage.php:477 
[0x00007f00b4ec49a0] getSingleton() /data/web/public/includes/src/__default.php:14044 
[0x00007f00b4ec4848] preDispatch() /data/web/public/includes/src/Mage_Adminhtml_Controller_Action.php:160 
[0x00007f00b4ec3b00] preDispatch() /data/web/public/includes/src/__default.php:13958 
[0x00007f00b4ec26e0] dispatch() /data/web/public/includes/src/__default.php:18331 
[0x00007f00b4ec20c0] match() /data/web/public/includes/src/__default.php:17865 
[0x00007f00b4ec1a98] dispatch() /data/web/public/includes/src/__default.php:20465 
[0x00007f00b4ec1908] run() /data/web/public/app/Mage.php:684 
[0x00007f00b4ec17f8] run() /data/web/public/index.php:87 

Lsof dice:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 
php5-fpm 24259 app 10uW REG 202,1 82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6 
php5-fpm 24262 app 10u REG 202,1 82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6 
php5-fpm 24351 app 10u REG 202,1 82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6 
php5-fpm 24357 app 10u REG 202,1 82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6 
php5-fpm 24358 app 10u REG 202,1 82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6 
php5-fpm 25563 app 10u REG 202,1 82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6 
php5-fpm 25564 app 10u REG 202,1 82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6 

Secondo strace, tutti questi processi sono in attesa per il gregge (LOCK_EX), anche colui che ha la bandiera W nell'output lsof sopra.

L'utilizzo della CPU durante questo incidente è vicino a 0.

Allora perché il primo session_start blocco, anche se sembra aver acquisito un blocco di scrittura sul file di sessione? Come posso eseguire il debug di questo ulteriore?

Questa è una discussione denominata "race condition with ajax and php sessions". In realtà, le richieste che attivano il problema sopra sono chiamate AJAX in modo coerente. Tuttavia, questo articolo stabilisce che:

Se hai utilizzato, sessione predefinita built-in di PHP gestione (che utilizza file), avrete mai incontrato il problema.

Così attualmente sono in perdita dove cercare dopo.

Answer 1

Sulle tue chiamate Ajax sto indovinando in quel file che hai session_start e da qualche parte nella tua directory/tmp nel tuo ubuntu php sta salvando le sue sessioni. Per risolvere il tuo problema devi eseguire il test di carico su tali script, ma può anche essere il db che potrebbe essere un fattore in cui non puoi vedere ad occhio nudo.

Prova qualcosa del genere: http://smartbear.com/products/qa-tools/load-testing-tool/ajax-load-testing/ come prova, forse puoi andare in fondo al problema. È inoltre necessario approfondire le sessioni relative a tali argomenti, inclusi quei singoli file che utilizzano le chiamate ajax.

È necessario impostare un tipo di test delle prestazioni rispetto a quelle chiamate al back-end che è possibile eseguire quando si verifica il problema. Gli strati sono PHP, PHP-FPM, Magento, Im ipotesi di MySQL, Ubuntu, connessione di rete e Apache?

Answer 2

Quando si dispone di uno script di importazione che richiede molto tempo, il browser sembra bloccarsi e non è più possibile accedere al sito Web. questo perché una richiesta sta leggendo e bloccando il file di sessione per prevenire la corruzione.

è possibile sia - utilizzare un gestore di sessione diversa con session_set_save_handler() - uso session_write_close() nello script di importazione, non appena non è necessario sessione di più (miglior momento è appena prima del tempo durante una parte avviene) , puoi session_start quando vuoi e tutte le volte che ti piace se il tuo script di importazione richiede variabili di sessione modificate.

http://php.net/manual/en/function.session-start.php

Answer 3

Vorrei consigli per controllare la tabella sessioni su Magento ... dal momento che memorizza le sessioni su un tavolo mysql si può avere un problema con il db ...

Answer 4

Trovo che la cosa migliore per memorizzare sessioni su un disco locale e non sul database.

Creare una directory denominata 'sessioni' nella directory principale, e poi avere tutte le sessioni scrivere là mettendo il seguente codice nella parte superiore di script a destra prima di chiamare "session_start()"

$session_path = $_SERVER['DOCUMENT_ROOT']; //this session path assumes you are not using a subdomain 
ini_set('session.save_path', $session_path.'/sessions/'); 

Il caricamento da file è più rapido del caricamento da un database. E php lo gestisce lo stesso, quindi opto per la velocità.

Answer 5

Qualcosa di sconosciuto sta bloccando il primo script e sta bloccando il resto.

PHP mantiene aperto il file di sessione per la scrittura fino al termine dello script. Ciò significa che se uno script si blocca o si blocca facendo qualcosa di lento, tutte le altre richieste dipendenti dalla sessione verranno bloccate fino al termine.

Due best practice: non avviare la sessione finché non ne hai bisogno e terminare esplicitamente la sessione con session_write_close() quando hai finito di cambiarla, specialmente prima di fare qualcosa di lento o potenzialmente buggato.

Quindi avrete solo 1 processo bloccato, invece di un utente bloccato.

Answer 6

Una buona pratica è quella di installare memecached per PHP e poi basta impostare questi valori:

session.save_handler = memcache 
session.save_path = “tcp://127.0.0.1:11211″