@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@core said: @VirMach
I submitted a suspension appeal in Ticket #619341
I paid the relevant fees as required, but because I did not receive the email notification, my server was suspended again (only 5 hours later)
I am not sure what happened to the server that caused the abnormal traffic. I cannot operate it immediately after the server is restored to normal, so please reinstall the system and restore it
If you're in a rush to receive a response, I can provide a rushed response. You won't like the response though. Any time a suspension appeal is taking a long time it means I really know I have to deny the appeal but waiting to see if I can convince myself otherwise.
A #619341 #791068
"This ticket is regarding a matter that was previously communicated. Please refer to previous communication by us."
I responded to the ticket, and you just closed it without responding to me
In fact, my server was suspended for some reason, I paid the fine, I waited for 2 hours, and didn't see the server back to normal, so I went to work
After 4 hours, I received a reminder that my server was suspended again
In this case, I didn't know when my server was back to normal, and I didn't receive any reminder of recovery. I think I was treated unfairly.
@FAT32 said:
Any tips on installing for 128MB RAM on VirMach servers? I tried a few ways via ISO/Netboot directly but all of them crashed/killed with OOM (Debian 9+, AlmaLinux 8+)
You can run debian 10 on a VPS with 128M RAM by using the official debian cloud image.
@core said: @VirMach
I submitted a suspension appeal in Ticket #619341
I paid the relevant fees as required, but because I did not receive the email notification, my server was suspended again (only 5 hours later)
I am not sure what happened to the server that caused the abnormal traffic. I cannot operate it immediately after the server is restored to normal, so please reinstall the system and restore it
If you're in a rush to receive a response, I can provide a rushed response. You won't like the response though. Any time a suspension appeal is taking a long time it means I really know I have to deny the appeal but waiting to see if I can convince myself otherwise.
A #619341 #791068
"This ticket is regarding a matter that was previously communicated. Please refer to previous communication by us."
I responded to the ticket, and you just closed it without responding to me
In fact, my server was suspended for some reason, I paid the fine, I waited for 2 hours, and didn't see the server back to normal, so I went to work
After 4 hours, I received a reminder that my server was suspended again
In this case, I didn't know when my server was back to normal, and I didn't receive any reminder of recovery. I think I was treated unfairly.
I don't know why you're mentioning paying anything. That did occur, but you're leaving out the part where I specifically refunded you the fee. Not that we're required to refund the fee. So $40 suspension fee was reduced to $5 as a courtesy. This is for the suspension and not the appeal. The appeal was rejected, and I also refunded the fee as I mentioned.
You also received this communication, Which did not include anything about it being unsuspended and resuspended, the appeal was just rejected. So the response you received is correct, as it was previously communicated. Refer to previous communication:
This cannot be unsuspended due to the severity. Heavy traffic even after suspension with packets being sent to it. I've refunded the appeal fee.
Reminder, your suspension reason as well:
Reason: Mass file sharing/torrent/high connection + high I/O
Let me know how it's unfair. You basically simultaneously broke at least four portions of our AUP in a really bad way, to an extreme level. You contributed to the entire node crashing. When I say you contributed I mean I believe you caused the node to crash but there's obviously a possibility that one other abuser at the same time may have exasperated the situation, and you would have instead only heavily overloaded the server. Your service also almost immediately crashed the server again after it came back online. You most definitely can rest assured that even if we billed you our $40 standard suspension fee, you would be receiving a big discount compared to our bill rate as this took would have cost in the $80 to $120 range if we were to bill you for the actual time it took to address, not including responding to you here or your tickets.
Your service is less than a 1/100th chunk of all the disk, yet your service by itself was 40% average or as high as 60% utilization rate, as in the proportion of total disk processing capacity being used by your service alone, with peak of around 5MB/s reads and 4MB/s writes at around 4kB to 8kB average request size. Other people use the server too, so this likely led to saturation, overloading, and a crash.
This also is not the first time this has happened and you should have honestly been suspended sooner (that's my fault for missing it.) Your usage for this server looks like it shifted some time around August 2024 in some way, with larger incoming network spikes about once every 1 to 3 months, with the accompanied heavy I/O spikes. When you were suspended, over 500 individual IP addresses were connecting to your service.
Although you'd still be breaking our terms of service, we can't provide a service to you, nor would we want to continue doing business with you in any other way, my recommendation for your use case, with another provider, would at the very least be an SSD service. That won't solve everything but it would get rid of the problem where your service is trying to do (according to SolusVM) 60MB/s to 200MB/s in reads to serve whatever content or whatever you're doing (and they're at 4kB to 8kB average request size.)
My math and analysis above may not be perfect and I've been awake for a very long time, if any of the above bothers you, refer to the most important portion of the message again, the only part that matters:
@core said: @VirMach
I submitted a suspension appeal in Ticket #619341
I paid the relevant fees as required, but because I did not receive the email notification, my server was suspended again (only 5 hours later)
I am not sure what happened to the server that caused the abnormal traffic. I cannot operate it immediately after the server is restored to normal, so please reinstall the system and restore it
If you're in a rush to receive a response, I can provide a rushed response. You won't like the response though. Any time a suspension appeal is taking a long time it means I really know I have to deny the appeal but waiting to see if I can convince myself otherwise.
A #619341 #791068
"This ticket is regarding a matter that was previously communicated. Please refer to previous communication by us."
I responded to the ticket, and you just closed it without responding to me
In fact, my server was suspended for some reason, I paid the fine, I waited for 2 hours, and didn't see the server back to normal, so I went to work
After 4 hours, I received a reminder that my server was suspended again
In this case, I didn't know when my server was back to normal, and I didn't receive any reminder of recovery. I think I was treated unfairly.
I don't know why you're mentioning paying anything. That did occur, but you're leaving out the part where I specifically refunded you the fee. Not that we're required to refund the fee. So $40 suspension fee was reduced to $5 as a courtesy. This is for the suspension and not the appeal. The appeal was rejected, and I also refunded the fee as I mentioned.
You also received this communication, Which did not include anything about it being unsuspended and resuspended, the appeal was just rejected. So the response you received is correct, as it was previously communicated. Refer to previous communication:
This cannot be unsuspended due to the severity. Heavy traffic even after suspension with packets being sent to it. I've refunded the appeal fee.
Reminder, your suspension reason as well:
Reason: Mass file sharing/torrent/high connection + high I/O
Let me know how it's unfair. You basically simultaneously broke at least four portions of our AUP in a really bad way, to an extreme level. You contributed to the entire node crashing. When I say you contributed I mean I believe you caused the node to crash but there's obviously a possibility that one other abuser at the same time may have exasperated the situation, and you would have instead only heavily overloaded the server. Your service also almost immediately crashed the server again after it came back online. You most definitely can rest assured that even if we billed you our $40 standard suspension fee, you would be receiving a big discount compared to our bill rate as this took would have cost in the $80 to $120 range if we were to bill you for the actual time it took to address, not including responding to you here or your tickets.
Your service is less than a 1/100th chunk of all the disk, yet your service by itself was 40% average or as high as 60% utilization rate, as in the proportion of total disk processing capacity being used by your service alone, with peak of around 5MB/s reads and 4MB/s writes at around 4kB to 8kB average request size. Other people use the server too, so this likely led to saturation, overloading, and a crash.
This also is not the first time this has happened and you should have honestly been suspended sooner (that's my fault for missing it.) Your usage for this server looks like it shifted some time around August 2024 in some way, with larger incoming network spikes about once every 1 to 3 months, with the accompanied heavy I/O spikes. When you were suspended, over 500 individual IP addresses were connecting to your service.
Although you'd still be breaking our terms of service, we can't provide a service to you, nor would we want to continue doing business with you in any other way, my recommendation for your use case, with another provider, would at the very least be an SSD service. That won't solve everything but it would get rid of the problem where your service is trying to do (according to SolusVM) 60MB/s to 200MB/s in reads to serve whatever content or whatever you're doing (and they're at 4kB to 8kB average request size.)
My math and analysis above may not be perfect and I've been awake for a very long time, if any of the above bothers you, refer to the most important portion of the message again, the only part that matters:
This cannot be unsuspended due to the severity.
Welcome to judgement day bro @core
Make ticket will make you naked here.
@VirMach said:
peak of around 5MB/s reads and 4MB/s writes at around 4kB to 8kB average request size.
We can do 5 MB/s no problem at normal providers such as ServerFactory / BuyVM / HOST-C.
Only VirmAche has a problem with such a measly speed.
Okay I feel like I may have to step in because I'm afraid that a good number of people will forget about the symbol right next to your name on this one. I'll go ahead and provide a weird way too in depth explanation.
@VirMach said:
peak of around 5MB/s reads and 4MB/s writes at around 4kB to 8kB average request size.
We can do 5 MB/s no problem at normal providers such as ServerFactory / BuyVM / HOST-C.
Only VirmAche has a problem with such a measly speed.
May be talking about a storage server ?
This isn't the exact model of hard drive used, but I'll provide it as a reference for anyone interested.
Hard drives are basically this magic voodoo thing which in my opinion shouldn't work as well as they do, or at all, but there's an arm that moves at astronomical speeds, something like maybe 2 to 4 miles an hour or 10-15 milliseconds to travel an inch and a half. Then there's the spinning platter, that rotates around 120 times a second, and you should think of this as some insanely large circular running track with many lanes/tracks. Like half a million of them. This would mean if someone was running in lane 1 versus 500,000 -- they'd obviously be running different distances, right? Well, the entire platter rotates 120 times a second so what that means is that the first lane/track is moving more (due to the different circumferences.) Or something like 5 times slower in the first track than the last.
Okay, except in our case, there's around 9 platters, and there's a whole 500,000 lane circular running track on both the top and bottom of each platter. There's one actuator arm assembly, and 18 read/write heads. The outer tracks hold more sectors, and in total there are around 35 billion sectors.
The big number you see in the screenshot above is the sequential speed, which is where the arm (for the most part, unless it has to change tracks) doesn't move, and just reads or writes data as the platter rotates. And it's the speed for the outer-most track. This means the inner-most track is probably closer to 125MB/s instead of the 280MB/s figure above. And this is only for sequential.
Now, in this specific abuse case, what was instead happening was random reads and writes of around an average of 4kB to 8kB, or 8 to 16 sectors. When it's a random write, the data gets written to random sectors. So now the arm has to change tracks, and it's not continuously writing to every sector that comes up as the platter spins. So it might take like 4 to 8 milliseconds for it to do that, then it has to wait for the sector to finish its rotation and reach that read/write head on the arm, which adds another 4 milliseconds. If the data being written is smaller than a sector, or smaller than 512 bytes in this case, it's even worse because it also has to read the sector, modify it, and then write the whole thing back. So notice how I said the average earlier which means it's possible in this case that this was also occurring for some portions of it that's way below the average. Once you add all this together, it means it one second, it can do significantly less operations, therefore, lower IOPS. The throughput or how much data can get written is the IOPS times the write size, and therefore the data transfer speed is significantly lower, and that's why you see that be around 4MB/s above.
There are some other things that makes random reads slower than random writes, queue depths and scheduling, and we're skipping many other things, and then we also have a RAID controller on top of all this. Technically with the RAID controller (RAID 10) and scheduling, reads can potentially be faster than writes in some cases.
View Ticket #553942
The server has been suspended and informed that I have abused IO. I have submitted a work order appeal and do you have time to handle it? Please apply to lift the suspension. Thank you
I have been using VirMach for almost 3 years and I purchased 15 units, all of which are annual VPS payments,. This is the first time I have encountered this situation
It has been suspended for more than 72 hours. When will it resume?
Peace on earth will come to stay, when we all live as LESbians every day.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
Comments
Thank you, so basically I boot into rescue more and dd into the disk right? Let me try
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
Yes, write an image from another server DD in rescue mode (make sure that image has your own password written to it)
Just like:
wget -O- “http://11.11.11.11/10disk.raw.xz” | xzcat | dd of=/dev/vda
Since the rescue mode version is quite old, you may also need to update some software like wget or xz or something like that.
Good luck!
Have the honor of being the crybaby who pays $20 for a 128MB VPS at VirMach in 2023.
Don't talk like that to our dear @FAT32
@FAT32 you can run any OS you want
I mean... the disk is only 3GB, I think I will not bother to even compress it with xz
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
Feeling a bit tired, let's call it a day.
Just because you can, doesn't mean you should.
Well it is the $1/yr package by VirMach this year, 1C128M3G
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
Oh, my God, it was so worth it!
Feeling a bit tired, let's call it a day.
Worth it but headache now...
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
Now I'm trying to reinstall a vps with 384MB of memory via netboot.xyz, which is equally difficult
Feeling a bit tired, let's call it a day.
If you don't count the space taken up by the swap file, the cloud image for debian 10 should take up less than 2G of space after installation.
Have the honor of being the crybaby who pays $20 for a 128MB VPS at VirMach in 2023.
netboot.xyz seems to be hard to run on low memory VPS, also recommend you to DD cloud image directly.
Have the honor of being the crybaby who pays $20 for a 128MB VPS at VirMach in 2023.
Alpine.
I had a similar package and Alpine just worked.
Thank you for your suggestion, it is true, but I have successfully installed it with netboot.xyz
Feeling a bit tired, let's call it a day.
We hear this spec is enough for Windows 98, complete with the FAT32 filesystem.
No hostname left!
A #619341 #791068
"This ticket is regarding a matter that was previously communicated. Please refer to previous communication by us."
I responded to the ticket, and you just closed it without responding to me
In fact, my server was suspended for some reason, I paid the fine, I waited for 2 hours, and didn't see the server back to normal, so I went to work
After 4 hours, I received a reminder that my server was suspended again
In this case, I didn't know when my server was back to normal, and I didn't receive any reminder of recovery. I think I was treated unfairly.
same here, I think I installed it with this script from Debian 10 template or from rescue
I once paid $2,400 for 64MB (yes Mega) to run Windows but I forget which Windows version that was.
@VirMach May I ask if PHXZ004 has completed the migration?
I don't know why you're mentioning paying anything. That did occur, but you're leaving out the part where I specifically refunded you the fee. Not that we're required to refund the fee. So $40 suspension fee was reduced to $5 as a courtesy. This is for the suspension and not the appeal. The appeal was rejected, and I also refunded the fee as I mentioned.
You also received this communication, Which did not include anything about it being unsuspended and resuspended, the appeal was just rejected. So the response you received is correct, as it was previously communicated. Refer to previous communication:
Reminder, your suspension reason as well:
Let me know how it's unfair. You basically simultaneously broke at least four portions of our AUP in a really bad way, to an extreme level. You contributed to the entire node crashing. When I say you contributed I mean I believe you caused the node to crash but there's obviously a possibility that one other abuser at the same time may have exasperated the situation, and you would have instead only heavily overloaded the server. Your service also almost immediately crashed the server again after it came back online. You most definitely can rest assured that even if we billed you our $40 standard suspension fee, you would be receiving a big discount compared to our bill rate as this took would have cost in the $80 to $120 range if we were to bill you for the actual time it took to address, not including responding to you here or your tickets.
Your service is less than a 1/100th chunk of all the disk, yet your service by itself was 40% average or as high as 60% utilization rate, as in the proportion of total disk processing capacity being used by your service alone, with peak of around 5MB/s reads and 4MB/s writes at around 4kB to 8kB average request size. Other people use the server too, so this likely led to saturation, overloading, and a crash.
This also is not the first time this has happened and you should have honestly been suspended sooner (that's my fault for missing it.) Your usage for this server looks like it shifted some time around August 2024 in some way, with larger incoming network spikes about once every 1 to 3 months, with the accompanied heavy I/O spikes. When you were suspended, over 500 individual IP addresses were connecting to your service.
Although you'd still be breaking our terms of service, we can't provide a service to you, nor would we want to continue doing business with you in any other way, my recommendation for your use case, with another provider, would at the very least be an SSD service. That won't solve everything but it would get rid of the problem where your service is trying to do (according to SolusVM) 60MB/s to 200MB/s in reads to serve whatever content or whatever you're doing (and they're at 4kB to 8kB average request size.)
My math and analysis above may not be perfect and I've been awake for a very long time, if any of the above bothers you, refer to the most important portion of the message again, the only part that matters:
^That's pretty damn clear, then.
Abuser, luser.
It wisnae me! A big boy done it and ran away.
NVMe2G for life! until death (the end is nigh)
i hope he bought it at a high price
I bench YABS 24/7/365 unless it's a leap year.
We can do 5 MB/s no problem at normal providers such as ServerFactory / BuyVM / HOST-C.
Only VirmAche has a problem with such a measly speed.
No hostname left!
May be talking about a storage server?
We set qBittorrent to 5000 KB/s (kilobytes per second) limit.
Both ServerFactory and BuyVM are on NVMe partition.
HOST-C is on HDD partition.
No hostname left!
Welcome to judgement day bro @core
Make ticket will make you naked here.
https://microlxc.net/
Okay I feel like I may have to step in because I'm afraid that a good number of people will forget about the symbol right next to your name on this one. I'll go ahead and provide a weird way too in depth explanation.
This isn't the exact model of hard drive used, but I'll provide it as a reference for anyone interested.
Hard drives are basically this magic voodoo thing which in my opinion shouldn't work as well as they do, or at all, but there's an arm that moves at astronomical speeds, something like maybe 2 to 4 miles an hour or 10-15 milliseconds to travel an inch and a half. Then there's the spinning platter, that rotates around 120 times a second, and you should think of this as some insanely large circular running track with many lanes/tracks. Like half a million of them. This would mean if someone was running in lane 1 versus 500,000 -- they'd obviously be running different distances, right? Well, the entire platter rotates 120 times a second so what that means is that the first lane/track is moving more (due to the different circumferences.) Or something like 5 times slower in the first track than the last.
Okay, except in our case, there's around 9 platters, and there's a whole 500,000 lane circular running track on both the top and bottom of each platter. There's one actuator arm assembly, and 18 read/write heads. The outer tracks hold more sectors, and in total there are around 35 billion sectors.
The big number you see in the screenshot above is the sequential speed, which is where the arm (for the most part, unless it has to change tracks) doesn't move, and just reads or writes data as the platter rotates. And it's the speed for the outer-most track. This means the inner-most track is probably closer to 125MB/s instead of the 280MB/s figure above. And this is only for sequential.
Now, in this specific abuse case, what was instead happening was random reads and writes of around an average of 4kB to 8kB, or 8 to 16 sectors. When it's a random write, the data gets written to random sectors. So now the arm has to change tracks, and it's not continuously writing to every sector that comes up as the platter spins. So it might take like 4 to 8 milliseconds for it to do that, then it has to wait for the sector to finish its rotation and reach that read/write head on the arm, which adds another 4 milliseconds. If the data being written is smaller than a sector, or smaller than 512 bytes in this case, it's even worse because it also has to read the sector, modify it, and then write the whole thing back. So notice how I said the average earlier which means it's possible in this case that this was also occurring for some portions of it that's way below the average. Once you add all this together, it means it one second, it can do significantly less operations, therefore, lower IOPS. The throughput or how much data can get written is the IOPS times the write size, and therefore the data transfer speed is significantly lower, and that's why you see that be around 4MB/s above.
There are some other things that makes random reads slower than random writes, queue depths and scheduling, and we're skipping many other things, and then we also have a RAID controller on top of all this. Technically with the RAID controller (RAID 10) and scheduling, reads can potentially be faster than writes in some cases.
that's different, above providers cache their HDD
I bench YABS 24/7/365 unless it's a leap year.
@VirMach said:
View Ticket #553942
The server has been suspended and informed that I have abused IO. I have submitted a work order appeal and do you have time to handle it? Please apply to lift the suspension. Thank you
I have been using VirMach for almost 3 years and I purchased 15 units, all of which are annual VPS payments,. This is the first time I have encountered this situation
It has been suspended for more than 72 hours. When will it resume?
Why do people quote a whole wall of text unrelated to their issue instead of just tagging VirMach ?
[rhetorical question]
Peace on earth will come to stay, when we all live as LESbians every day.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add