PHP-FPM che crasha sotto carico su VPS: come ho diagnosticato un OOM killer silenzioso su un portale Laravel con 200 utenti concorrenti
Un portale B2B Laravel su VPS OVH andava in 502 Bad Gateway ogni giorno tra le 10 e le 11 del mattino - l'ora di punta degli ordini. PHP-FPM veniva ucciso dall'OOM killer del kernel perché pm.max_children era impostato a 200 su un server con 8 GB di RAM e worker da 80 MB ciascuno. La matematica non tornava: 200 × 80 MB = 16 GB, il doppio della RAM disponibile. Diagnosi con dmesg, tuning di pm.max_children, auto-restart con systemd e prevenzione. Continua a leggere
Ultima modifica:
Su un VPS Contabo con un gestionale Laravel 10, i backup automatici con spatie/laravel-backup fallivano da tre mesi - disco pieno sullo storage S3, credenziali scadute, e il notification channel configurato su un webhook Slack che non esisteva più. Il titolare l'ha scoperto quando ha avuto bisogno di un restore. Diagnosi delle cause di fallimento, ripristino della pipeline, test di restore verificato e monitoring che avvisa davvero quando qualcosa non funziona. 
Un VPS Hetzner con Redis 6 esposto su 0.0.0.0:6379 senza password. Un attaccante ha usato il motore Lua integrato per scrivere un crontab che scaricava un cryptominer Monero. CPU al 100%, Laravel a 12 secondi di response time, e nessuno sapeva perché. Il caso reale di un SaaS piemontese del luglio 2025, la diagnosi in 40 minuti, l'eradicazione e l'hardening di Redis per impedire che succeda di nuovo. 
Un e-commerce Laravel su Hetzner inviava 800 email transazionali al giorno tramite Postfix locale. Il 40% finiva in spam su Gmail, il 15% non arrivava affatto su Outlook. Il titolare non lo sapeva perché nessuno monitorava i bounce. Diagnosi: niente SPF, niente DKIM, niente DMARC, IP del VPS in due blacklist. La soluzione non era "aggiustare Postfix" - era ripensare come un'applicazione Laravel in produzione deve gestire le email transazionali nel 2025. 
Un VPS OVH con Debian 11 e Laravel 10 non vedeva un apt upgrade da 14 mesi. 247 pacchetti arretrati, 38 security patch mancanti, OpenSSH con regreSSHion non patchato. Il proprietario non lo sapeva - l'app funzionava. Il protocollo per aggiornare un server di produzione senza downtime: snapshot, dry run, upgrade in due fasi, needrestart, verifica applicativa e setup unattended-upgrades. 
Dopo aver recuperato server e credenziali, resta il problema vero: 85.000 righe di codice Laravel senza documentazione, zero test, business logic nei Blade template, e un titolare che deve sapere entro venerdì cosa può rompere e cosa si può toccare. Il metodo in 48 ore: scansione automatica con PHPStan, mappatura rotte, analisi schema, tracciamento flusso di business e consegna di una mappa di rischio prioritizzata. 
Un CRM Laravel 9 per una PMI logistica veneta è stato compromesso perché un file .env con l'APP_KEY era stato committato su un repository GitHub pubblico due anni prima. L'attaccante ha sfruttato CVE-2018-15133 per ottenere esecuzione remota di codice tramite cookie deserializzato, ha piantato una backdoor in un comando Artisan e ha esfiltrato 4.200 record clienti. Cinque giorni di lavoro: contenimento senza distruzione delle prove, forensics applicativa, remediation e hardening permanente. 
Un VPS Contabo con un e-commerce B2B Laravel è rimasto fermo 60 ore - dal venerdì pomeriggio al lunedì mattina - perché il certificato SSL era scaduto e nessuno se n'era accorto. 80 ordini persi, circa 35.000 euro di fatturato evaporato in un weekend. Il problema non era il certificato: era l'assenza totale di monitoring. Prometheus, Grafana, Alertmanager, health check Laravel e regole di alerting concrete: ecco lo stack che installo su ogni VPS che prendo in carico. 
Una PMI lombarda con 8 sviluppatori e un monolite Laravel 10 lento aveva speso quattro mesi e 120.000 euro per migrare a microservizi. Risultato: tre servizi parzialmente funzionanti, zero in produzione, latenza raddoppiata e metà del team impegnato in infrastruttura Docker anziché in feature. La mia raccomandazione: fermare la migrazione, modularizzare il monolite con bounded context, e risolvere i veri problemi di performance. In due settimane il team era tornato produttivo. 
Un database MySQL da 12 GB su un VPS Contabo, un report mensile che impiegava 47 minuti, 38 indici su una tabella di cui 12 mai utilizzati, e una codebase Laravel 9 cresciuta per cinque anni senza che nessuno aprisse mai un EXPLAIN. Il caso reale di una PMI emiliana del marzo 2025: diagnosi con slow query log e EXPLAIN ANALYZE, invisible indexes per eliminare indici fantasma, tuning InnoDB, schema refactoring con migration sicure su tabelle da milioni di righe.