6 MB/s pe o alocare I/O de 100 MB/s
Un ZIP de 43 MB dura 10 până la 20 de secunde. CPU rămânea jos. IOPS rămânea jos. Patru teste direcționale au izolat scrierea persistentă. Hostinger a confirmat ulterior că limitele de resurse ale contului au trebuit reaplicate.
Aplicația revenea mereu în explicație. Testul de filesystem indica mereu mai jos.
Simptomul inițial apărea la crearea backupurilor ZIP într-un file manager PHP. Aplicația era un suspect firesc. Investigația a coborât sub stratul aplicației și a măsurat același payload de 16 MB prin patru combinații de sursă și destinație.
Ambele trasee care se terminau pe storage persistent s-au stabilizat în jurul valorii de 6 MB/s. Ambele trasee care se terminau în RAM au ajuns la sute sau mii de MB/s. Un simplu copy a reprodus comportamentul fără ZipArchive, fără scanarea directoarelor, fără browser și fără cod de download.
La 22 septembrie, Hostinger a trimis o rezoluție scrisă în care a precizat că problema fusese identificată și rezolvată din partea sa și că limitele corecte de resurse ale contului fuseseră reaplicate la 07:36 UTC.
Testul de izolare în patru direcții
Același server, aceeași familie de procese, aceeași dimensiune a payloadului. S-au schimbat doar clasa de storage a sursei și a destinației.
Destinația explică separarea. O destinație persistentă a rămas în jurul valorii de 6 MB/s indiferent dacă sursa era pe disk sau în RAM.
Verificare încrucișată cu ZipArchive
Același tipar a apărut cu ZIP STORE. Compresia a fost scoasă din ecuație, rămânând citirea fișierului, munca de container ZIP și scrierea destinației.
| Traseu | Timp total | Rată sursă | CPU / timp total |
|---|---|---|---|
| ZipArchive STORE: disk -> disk | 2.637 s | 6.067 MB/s | 0.0218 |
| ZipArchive STORE: disk -> RAM | 0.039 s | 410.541 MB/s | 0.9966 |
| ZipArchive STORE: RAM -> disk | 2.629 s | 6.087 MB/s | 0.0219 |
| ZipArchive STORE: RAM -> RAM | 0.035 s | 457.875 MB/s | 0.9970 |
Schimbarea backendului ZIP nu ar elimina costul scrierii persistente. Rezultatul brut cu copy a reprodus deja aceeași clasă de timp.
Procesul petrecea timpul în așteptare, nu în calcul
Copierea lentă de 16 MB către storage persistent a consumat aproximativ 2,61 secunde wall time, iar PHP aproximativ 0,016 secunde CPU. Raportul CPU față de wall time a fost aproximativ 0,006. RAM spre RAM a rulat cu un raport apropiat de 1,0.
Diferența contează. Procesul își petrecea aproape tot timpul scurs în afara muncii CPU. Hostinger a raportat și 100% Throughput I/O în același context în care IOPS era aproximativ 14%, iar CPU aproximativ 5%.
Ce au exclus măsurătorile
Browserul și rețeaua locală
Blocajul s-a reprodus în interiorul contului de hosting prin operații de filesystem. Nu a fost necesar niciun transfer către client.
ZipArchive ca motor
Atât copy brut, cât și ZipArchive STORE au ajuns în jurul valorii de 6 MB/s când destinația era storage persistent.
Scanarea directoarelor
O scanare completă de metadata a arborelui a terminat în aproximativ 33 ms. Înregistrarea fișierelor în ZIP a fost măsurată tot în milisecunde. Așteptarea lungă apărea la scrierea și închiderea destinației.
Saturația IOPS și CPU
Hostinger a raportat aproximativ 14% IOPS și 5% CPU, în timp ce Throughput I/O a ajuns la 100% și a înregistrat fault-uri.
Cronologia suportului
Benchmark trimis cu rezultate direcționale exacte
Solicitarea cerea explicit verificarea storage, LVE și backend și preciza că simplul copy reproducea problema independent de logica aplicației PHP.
Hostinger a confirmat tiparul resurselor
Interfața de suport a raportat limita Throughput I/O la 20.480 KB/s, fault-uri I/O repetate, IOPS redus și CPU redus. A mai spus că datele disponibile erau compatibile cu throttling de throughput.
Răspunsul a revenit la manager.php
Suportul a indicat scanarea repetată a directoarelor de către manager.php drept explicație probabilă pentru activitatea I/O și a spus că site-ul se deschidea normal. Explicația nu răspundea benchmarkului cu copy brut.
Benchmarkul a fost repetat în discuție, iar cazul a fost escaladat
După reluarea celor patru trasee, agentul a recunoscut că benchmarkul izola scrierile pe storage persistent și a spus că problema va fi escaladată pentru verificare la nivel de infrastructură.
Hostinger a reaplicat limitele contului
Actualizarea finală a spus că problema fusese complet identificată și rezolvată din partea Hostinger. Echipa a reaplicat limitele corecte de resurse și a precizat că alocarea contului fusese restabilită la 100 MB/s I/O, 5.120 IOPS, 4,5 GB RAM și 300% CPU.
Costul tehnic al unui diagnostic trimis spre stratul greșit
După ce un copy brut de filesystem a reprodus blocajul, revenirea la scanarea directoarelor a trimis din nou timpul de investigație către un strat pe care măsurătorile îl separaseră deja de traseul lent. Au urmat instrumentare suplimentară, modificări defensive în aplicație, teste de regresie și noi runde de suport înainte de verificarea infrastructurii.
O explicație de suport produce cost operațional atunci când un inginer acționează pe baza ei. Standardul tehnic minim este simplu: explicația trebuie să acopere traseul măsurat. Dacă un copy RAM spre disk de 16 MB petrece 2,61 secunde în așteptare, iar RAM spre RAM termină în milisecunde, teoria scanării aplicației trebuie să explice acea separare înainte de a fi tratată drept diagnostic.
Dosarul public de dovezi
Capturile de mai jos sunt decupate la schimbul relevant. Identificatorii de cont și istoricul de suport fără legătură sunt eliminați din copia publică. Originalele rămân în arhiva privată de dovezi.
Corecția făcută de provider
Hostinger a scris că problema fusese complet identificată și rezolvată din partea sa și că echipa reaplicase limitele corecte de resurse.
Același mesaj a enumerat alocarea restabilită: 100 MB/s I/O, 5.120 IOPS, 4,5 GB RAM și 300% CPU. Înainte, hPanel afișa un plafon Throughput I/O de 20.480 KB/s și înregistra fault-uri I/O în intervalul de test.
Succesiunea schimbă diagnosticul. Modificările făcute în aplicație în timpul investigației pot rămâne optimizări utile, dar nu pot explica o limită de resurse la nivel de cont despre care providerul spune ulterior că a trebuit reaplicată.
Statusul verificării la publicare
La 22 septembrie 2026, ora 19:07 UTC, același test direcțional de 16 MB a fost rulat din nou după corecția raportată de Hostinger. Destinațiile persistente au terminat dramatic mai repede decât în baza din 20 septembrie. Scrierea sincronizată RAM spre persistent a încheiat la 678,311 MB/s.
Același payload de 16 MB, înainte și după
Panoul nu rulează un benchmark pe server. Redă în browser măsurătorile deja publicate ca separarea să se vadă direct: înainte de corecție, cele două destinații persistente rămâneau în jur de 6 MB/s; după corecție, aceleași trasee de cod au terminat dramatic mai repede.
Replay vizual bazat strict pe măsurătorile publicate. Componenta nu accesează filesystemul, nu rulează probe live, nu execută shell, nu apelează API-uri și nu face requesturi de rețea. Timpii numerici sunt timpii măsurați; traseele foarte rapide pot termina într-un singur frame al ecranului.
Aceste valori sunt rate de finalizare la nivelul aplicației pentru un payload scurt de 16 MB. Page cache și I/O bufferizat le pot ridica peste un plafon de resurse al planului, deci rezultatul relevant este schimbarea înainte și după pe aceleași trasee de cod. Varianta sincronizată RAM spre persistent a încheiat și ea la 678,311 MB/s.
Note tehnice pentru review
De ce a contat /dev/shm
/dev/shm era un device tmpfs separat. Documentația Linux descrie tmpfs ca storage susținut de memorie. A oferit o destinație RAM practică fără schimbarea PHP sau a protocolului aplicației.
Ce a măsurat de fapt traseul de 1427 MB/s
Valoarea persistent spre RAM este sensibilă la cache și nu trebuie citită drept throughput brut al device-ului. Rolul ei aici este comparativ: în același test, citirile persistente au terminat rapid, iar destinațiile persistente au rămas repetat lente.
De ce spike-ul hPanel și media de 6 MB/s pot exista simultan
Hostinger descrie graficul drept throughput agregat între disk și RAM și marchează separat atingerile scurte de limită față de media generală. CloudLinux descrie limitele LVE I/O drept plafoane de throughput care throttling-uiesc procesele când limita este atinsă.
De ce IOPS nu explică acest caz
Throughput măsoară bytes pe secundă. IOPS măsoară operații pe secundă. Metricile de suport arătau plafonul de throughput atins, în timp ce IOPS rămânea mult sub propriul plafon.
Referințe tehnice primare
- Hostinger: verificarea utilizării resurselor
- CloudLinux: limite LVE și throttling I/O
- Kernel Linux: tmpfs și /dev/shm
Ce păstrez din incident
O explicație de suport trebuie să se potrivească măsurătorilor. Când nu se potrivește, cobori un strat și reduci reproducerea până când rămâne numai subsistemul disputat.
Pasul decisiv aici a fost intenționat banal: un payload, patru direcții, copy brut, dimensiune fixă, cronometrare server-side. Matricea mică a făcut mai multă muncă de diagnostic decât încă o rundă de rescrieri în aplicație.
Păstrează timestampurile, rezultatele brute și răspunsurile providerului. Corecția finală capătă greutate tocmai pentru că măsurătorile și explicațiile anterioare rămân vizibile lângă ea.