New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Looks like my disk is completely locked up with this last yabs run. Never seen 0 iops before.
Would this be considered completely unusable?
`fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):---------------------------------
The problem has been resolved, the server has been improved, thank you very much!
I look forward to continuing to use your service!
whats your steal and IOwait
I check this soon
full
Order Number 8289368954
Order Number: 3613198812
+10 GB Extra Storage
Thanks
Steal isn't bad. IOwait is ridonkulous.
Hetrixtools has a nice graph showing the trending performance over the last month.
[Edit cropping]
Order Number: 5489480898
Thanks!
I'll ask again since you sidestepped the question: Would you consider a vps in this state to be completely unusable?
Follow up questions:
If no, thanks for benchmarking performance criteria with your service.
If yes, why has this been allowed to persist for so long?
Order Number #7608092328
I'd prefer extra storage or extra RAM. Thanks a lot
Order Number: 8145111108
I'm still in time?
Order Number: 3899367486
Prefer Port Upgrade to 10G
or +1 GB Extra RAM pls thanks.
Order Number: 8273781588
Please +1 vCore. Thanks.
To answer your question, completely unusable its an exaggeration . The servers do get overloaded when lots of people are uploading GBs at the same moment, thats why i get spikes like this.
https://ibb.co/PvB0bcyp
I think some kind of io optimization is needed, and deluxhost said they are planning to work on this soon.
If your spikes looked like this and you were getting gateway timeouts every ~2 minutes you might be singing a different tune. Any action that requires asynchronous loading seems doomed to error. Let's take a closer look and zoom in from a 30 day span to a 3 hour span:
Edit (cropping)
This is from a server that is basicly idling: a few containers running but no traffic to speak of and only 1 user. I don't believe this level of service degradation can be optimized away, though I'd be happy to be wrong. They've been planning to "work on this soon" for the last month, or roughly 8% of the Service term.
While I appreciate your opinion, I'm still keenly interested to get the providers opinion on the performance to date.
Don't get me wrong. I'm on the same boat. I'm really interested to hear their side on the disk issues as well.
Hello,
The behavior you are observing has occurred intermittently over the past weeks and is related to periodic saturation of the shared SATA storage layer, not to disk failure. This is one of the reasons we previously announced the planned migration from SATA to NVMe, which directly addresses I/O queueing and latency under contention.
In many cases, this situation has already been mitigated or fully resolved through applied improvements to storage scheduling and capacity distribution. Where necessary, we have also taken action against disk-abusive workloads that negatively impact other users on the same host.
While this behavior is not ideal, it remains intermittent and the service has stayed operational, which is why it has not been classified as a fault condition.
For completeness, we responded to your ticket within one hour. At the time of writing, we have not yet received a reply from you.
We remain available should you wish to continue the discussion or review alternative solutions.
Knowing which node is affected would help us solve the problem.
In short, is there a problem? Yes.
Can we solve it? Yes.
My order: 1412-7865-2025
If you mean intermittent by every ~2 minutes then yes it is a very intermittent problem. The images from hetrixtools showing systematic iowait over the last month, not an occasional blip.
Yes your support team was quick to reply to my ticket, if not to answer my query.
As an end user, perhaps I don't understand the administrative side of your hypervisor panel in connection with the billing panel; I know that when I open a ticket there is a dropdown menu to select an affected service. It seems to me that this should be sufficient means to identify the affected node; this is only an assumption and I may very well be wrong, yet it seems like common sense to me.
If there is no means for you to identify an affected node from a ticket-referenced service then I owe you and your staff an apology, and my long wait is entirely my own fault.
If, on the other hand, your support has the ability to identify a node from a referenced service, yet they neglected to do so (for whatever reason) then your support could use some improvement.
As it stands, since it seems that you are waiting on hardware to fix a systemic problem, I'll power down the affected services and try again if NVMe drives are ever installed.
Thank you for the clarification.
To address this point directly: we do not see which specific service you selected as “affected” in the ticket. Our support system does not automatically expose that information to the technician handling the request.
For this reason, our support team replied asking you to specify which server is experiencing the issue, especially since you have more than one service with us. This step is necessary to immediately identify the host node and isolate or investigate the problem. Unfortunately, we did not receive a response to that request, which prevented us from proceeding further at that time.
As for immediate solutions, we can offer to move the affected VPS free of charge to a more performant NVMe-backed node, while we continue to investigate what is happening on the current node.
At this stage, without knowing exactly which service was affected and without follow-up data, we cannot determine precisely what occurred on that node.
We remain available to proceed as soon as you confirm which server is impacted in the ticket.
I do apologize, however, for any problems you may have encountered, and you will be compensated for them.
Please deliver my humble apologies to your staff for not following up in a timely manner. My frustrations are my own and I do not seek any compensation for them. The loss would be more valuable as a lesson learned.
The offer to move to a more performant node is entertaining. I would graciously accept it if you could perform a seamless migration. If a move would require obtaining a new IP address I'd just as soon wait for new drives to be installed. I've recently migrated two services elsewhere and I prefer not to take on another if I have a choice in the matter.
Thank you for your message, and please don’t worry about apologies at all. We fully understand how frustrating these situations can be. When issues occur and they are on our side, the responsibility is ours, not yours.
If you can simply confirm in the ticket which service is affected (or if multiple services on different nodes are involved), I will personally handle the migration for you.
The migration can be performed live, within a few minutes, without data loss, and with the same IP address preserved, should you wish to proceed. Everything will remain exactly as it is now, files, configuration, and services.
Once we have that confirmation in the ticket, we can move the service to a more performant NVMe node immediately while we continue investigating what is happening on the current one.
We’re here when you’re ready.
@DeluxHost will there be a W-5 restock anytime soon?
yes!
why your support answer ticket just once a day ? ...... plz add more agent !
Hello, unfortunately, our support team is currently busy handling a very high volume of tickets, which is increasing the response time.
I'm very sorry, but we're working on it. We'll get back to you within a few hours.
I sent my order above, I hope you haven't read it yet.
My order: 1412-7865-2025
Is these results good or bad, system real slow.
bad. im getting 33 steal too