6 MB/s på en I/O-tildeling på 100 MB/s
En ZIP på 43 MB tog 10 til 20 sekunder. CPU forblev lav. IOPS forblev lav. Fire retningsbestemte tests isolerede skrivning til vedvarende lager. Hostinger bekræftede senere, at kontoens ressourcegrænser skulle genanvendes.
Applikationen blev ved med at komme tilbage i forklaringen. Filesystem-testen pegede konsekvent længere ned.
Det oprindelige symptom viste sig ved oprettelse af ZIP-backups i en PHP-filmanager. Applikationen var derfor en naturlig mistænkt. Undersøgelsen gik under applikationslaget og målte den samme 16 MB payload gennem fire kombinationer af kilde og destination.
Begge veje, der endte på vedvarende lager, stabiliserede sig omkring 6 MB/s. Begge veje, der endte i RAM, nåede hundredvis eller tusindvis af MB/s. En rå copy-operation gengav adfærden uden ZipArchive, mappescanning, browsertrafik eller downloadkode.
Den 22. september sendte Hostinger en skriftlig løsning, hvor udbyderen oplyste, at problemet var identificeret og løst på deres side, og at de korrekte ressourcegrænser var blevet genanvendt kl. 07.36 UTC.
Firevejs-isolationstesten
Samme server, samme procesfamilie, samme payload-størrelse. Kun lagertypen for kilde og destination blev ændret.
Destinationen forklarer forskellen. En vedvarende destination blev omkring 6 MB/s, uanset om kilden lå på disk eller i RAM.
Krydstjek med ZipArchive
Det samme mønster optrådte med ZIP STORE. Komprimering blev fjernet fra ligningen, så fil-læsning, ZIP-containerarbejde og destinationsskrivning stod tilbage.
| Vej | Forløbet tid | Kildehastighed | CPU / forløbet tid |
|---|---|---|---|
| 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 |
Et andet ZIP-backend ville ikke fjerne omkostningen ved vedvarende skrivning. Den rå copy-test gengav allerede samme klasse af ventetid.
Processen ventede i stedet for at beregne
Den langsomme 16 MB copy til vedvarende lager brugte cirka 2,61 sekunders wall time, mens PHP brugte cirka 0,016 sekunders CPU-tid. Forholdet mellem CPU og wall time var cirka 0,006. RAM til RAM kørte med et forhold tæt på 1,0.
Forskellen er vigtig. Processen brugte næsten hele den forløbne tid uden for CPU-arbejde. Hostinger rapporterede samtidig 100% Throughput I/O, mens IOPS lå omkring 14% og CPU omkring 5%.
Hvad målingerne udelukkede
Browser og lokalt netværk
Flaskehalsen blev gengivet inde i hostingkontoen med filesystem-operationer. Ingen klientoverførsel var nødvendig.
ZipArchive som motor
Både rå copy og ZipArchive STORE endte omkring 6 MB/s, når destinationen var vedvarende lager.
Mappescanning
En fuld metadatascanning af træet sluttede på cirka 33 ms. Registrering af filer i ZIP blev også målt i millisekunder. Den lange ventetid opstod ved skrivning og lukning af destinationen.
IOPS- og CPU-mætning
Hostinger rapporterede cirka 14% IOPS og 5% CPU, mens Throughput I/O nåede 100% og registrerede faults.
Supportforløbet
Benchmark indsendt med præcise retningsresultater
Anmodningen bad specifikt om undersøgelse af storage, LVE og backend og oplyste, at rå copy gengav problemet uafhængigt af PHP-applikationslogik.
Hostinger bekræftede ressourcemønsteret
Supportgrænsefladen rapporterede Throughput I/O-grænsen som 20.480 KB/s, gentagne I/O-faults, lav IOPS og lav CPU. Den oplyste også, at de tilgængelige data var forenelige med throughput-throttling.
Svaret vendte tilbage til manager.php
Support pegede på gentagen mappescanning i manager.php som sandsynlig forklaring på I/O-aktiviteten og oplyste, at selve webstedet testede normalt. Forklaringen adresserede ikke benchmarken med rå copy.
Benchmarken blev gentaget i samtalen, og sagen blev eskaleret
Efter at de fire veje blev gentaget, anerkendte agenten, at benchmarken isolerede skrivning til vedvarende lager, og oplyste at sagen ville blive eskaleret til infrastrukturkontrol.
Hostinger genanvendte kontoens grænser
Den afsluttende opdatering oplyste, at problemet var fuldt identificeret og løst på Hostingers side. Teamet genanvendte de korrekte ressourcegrænser og oplyste, at kontoens tildeling var gendannet til 100 MB/s I/O, 5.120 IOPS, 4,5 GB RAM og 300% CPU.
Den tekniske pris for et spor mod det forkerte lag
Da en rå filesystem-copy havde gengivet flaskehalsen, sendte en fortsat forklaring om mappescanning undersøgelsestid tilbage til et lag, som målingerne allerede havde adskilt fra den langsomme vej. Det gav ekstra instrumentering, defensive applikationsændringer, regressionstests og flere supportrunder før infrastrukturgennemgangen.
En supportforklaring har en reel driftsomkostning, når en ingeniør handler på den. Det tekniske minimumskrav er enkelt: forklaringen skal kunne redegøre for den målte vej. Når en 16 MB RAM-til-disk copy bruger 2,61 sekunder på ventetid, mens RAM-til-RAM afsluttes på millisekunder, skal en teori om applikationsscanning forklare den forskel, før den kan bruges som diagnose.
Offentlig dokumentation
Skærmbillederne nedenfor er beskåret til den relevante udveksling. Kontoidentifikatorer og uvedkommende supporthistorik er fjernet fra den offentlige kopi. Originalerne bevares i det private dokumentationsarkiv.
Udbyderens korrektion
Hostinger skrev, at problemet var fuldt identificeret og løst på deres side, og at teamet havde genanvendt de korrekte ressourcegrænser.
Den samme besked angav den gendannede tildeling som 100 MB/s I/O, 5.120 IOPS, 4,5 GB RAM og 300% CPU. Tidligere viste hPanel et Throughput I/O-loft på 20.480 KB/s og registrerede I/O-faults i testintervallet.
Forløbet ændrer diagnosen. Applikationsændringer fra undersøgelsen kan stadig være nyttige optimeringer, men de kan ikke forklare en ressourcegrænse på kontoniveau, som udbyderen senere oplyser skulle genanvendes.
Verifikationsstatus ved publicering
Den 22. september 2026 kl. 19:07 UTC blev den samme retningsbestemte 16 MB-test kørt igen efter Hostingers rapporterede korrektion. Vedvarende destinationer afsluttede markant hurtigere end baselinen fra 20. september. Den synkroniserede RAM til vedvarende skrivning afsluttede ved 678,311 MB/s.
Den samme 16 MB payload, før og efter
Panelet kører ikke en serverbenchmark. Det afspiller de offentliggjorte målinger i browseren, så forskellen kan ses direkte: før korrektionen lå de to vedvarende destinationer omkring 6 MB/s, og efter korrektionen afsluttede de samme kodeveje markant hurtigere.
Visuelt replay baseret udelukkende på de offentliggjorte målinger. Komponenten tilgår ikke filsystemet, kører ingen live probe, udfører ingen shell-kommandoer, kalder ingen API og laver ingen netværksrequest. De viste tider er de målte afslutningstider; meget hurtige veje kan afslutte inden for én skærmframe.
Disse værdier er korte 16 MB-gennemførelseshastigheder på applikationsniveau. Page cache og bufferet I/O kan løfte dem over et ressource-loft i planen, så det væsentlige resultat er ændringen før og efter på de samme kodeveje. Den synkroniserede RAM til vedvarende variant afsluttede også ved 678,311 MB/s.
Tekniske noter til review
Hvorfor /dev/shm var vigtig
/dev/shm var en separat tmpfs-enhed. Linux-dokumentationen beskriver tmpfs som hukommelsesunderstøttet lager. Det gav en praktisk RAM-destination uden at ændre PHP eller applikationsprotokollen.
Hvad 1427 MB/s-vejen faktisk målte
Tallet vedvarende til RAM er cache-følsomt og bør ikke læses som rå enhedsgennemløb. Dets værdi her er sammenligningen: under samme test afsluttede vedvarende læsninger hurtigt, mens vedvarende destinationer gentagne gange stoppede op.
Hvorfor hPanel-spiken og gennemsnittet på 6 MB/s kan eksistere samtidig
Hostinger beskriver grafen som aggregeret throughput mellem disk og RAM og markerer korte limit-hits separat fra det samlede gennemsnit. CloudLinux beskriver LVE I/O-grænser som throughput-lofter, der throttler processer, når grænsen nås.
Hvorfor IOPS ikke forklarer denne sag
Throughput måler bytes pr. sekund. IOPS måler operationer pr. sekund. Supportmålingerne viste throughput-loftet ramt, mens IOPS forblev langt under sit eget loft.
Primære tekniske referencer
- Hostinger: kontrol af ressourceforbrug
- CloudLinux: LVE-grænser og I/O-throttling
- Linux-kernen: tmpfs og /dev/shm
Det jeg tager med fra hændelsen
En supportforklaring skal passe til målingerne. Hvis den ikke gør, gå et lag længere ned og reducer reproduktionen, indtil kun det omstridte subsystem er tilbage.
Det afgørende trin var bevidst kedeligt: én payload, fire retninger, rå copy, fast størrelse, server-side timing. Den lille matrix udførte mere diagnostisk arbejde end endnu en omgang applikationsomskrivning.
Bevar timestamps, rå resultater og udbyderens svar. Den afsluttende korrektion får vægt, fordi de tidligere målinger og forklaringer forbliver synlige ved siden af den.