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.
★ VirMach ★ RYZEN ★ NVMe ★★ $8.88/YR- 384MB ★★ $21.85/YR- 2.5GB ★ Instant ★ Japan Pre-order ★ & More
This discussion has been closed.
Comments
What exactly are you running? What debian are you installing? Try installing debian 11 minimal and if you still crash from apt commands then something's really wrong here. 384 MB of ram is definitely enough.
You only get shutdown if there's really not enough ram and no processes to kill. But you know, maybe this is a result of overselling ram.
It might be better if you don't speculate on things like that. People tend to pick those up as facts and then repeat them over and over again. Also, I'm pretty sure that's not how that works.
Then explain how Alma is not plagued by this problem?
Yeah, unfortunately I can't edit this now. I have never tried to overcommit ram so I don't know what really happens when you do that. I was thinking maybe there's no processes to kill, and no ram from the hypervisor and that's what shuts down the server. I think getting shutdown from oom should be a really uncommon scenario.
So the qualifier here is if he installs the minimum image and crashes from apt commands, it's not on him.
The guy never mentioned what debian he was installing or what processes he was running. There was also someone who apparently gets random shutdowns with 768 MB of ram. Either these people are running many processes, or the problem is specific to a single node.
@VirMach said earlier on that 67% of the orders were activated.
I think its more than likely that the OS is reaching an OOM situation due to whatever combination of OS/Software etc each person has installed. 768MB can run a number of things but it can't run a number of things aswell. VPS's with such low amounts of RAM need to be optimized aswell by each person, there may be services that can be removed depending on the use-case of each person or other optimizations that should be done so that the VPS doesn't need more than the assigned RAM. Also SWAP can be used.
Overselling RAM is normal and occurs with all providers but it doesn't affect stability in any way because not all users will use 100% of their RAM at all times - the opposite actually as a lot of users will just idle their machines or use their machines for VPN's or other similar usage.
Virmach has said a few times that it happens across all nodes which rules that theory out.
I'm on SJVKM7 and I haven't been migrated although I got a email 21 March saying it would happen next day.
Should I be concerned?
It does not affect stability when done right. Shutdowns can indeed happen due to ram overselling. The only explanations for the oom shutdowns are the users running too many processes or the way ram is managed.
If I could edit my original post I would mention that ram overselling is only a potential reason for random shutdowns.
Potential in theory perhaps.
Yeah definitely shutdowns can happen due to ram overselling, but when the logs of the VPS have OOM errors then as you said its users running too many processes etc.
No, it just kept getting delayed. Good news is I think we're ready to announce it again today and if the script gets fixed you'll be able to migrate it yourself without data as soon as today.
Please don't flame me if I'm wrong.
Look at the first page:
EARLY BIRD SPECIAL: ADDITIONAL 20% DISCOUNT. LIMIT ONE. ONLY THIS WEEKEND.
Use coupon code "EARLYBIRDPREORDER2022" before 03/14/2021 or order biennially for the additional discount level without requiring a coupon.
Biennial pre-orders in Tokyo will also receive a guaranteed spot on Gen4/Ryzen 5000 Series processor server and will be activated in the first pre-order batch for that location.
Absolutely not true and also not how it works at all.
We have been very very very careful with RAM numbers, but also put nodes with enough disk to where if RAM is not a problem, then we can oversell it to a higher level. Right now it actually looks that way, as in we can oversell RAM more because it's not being used really but didn't. Maybe I'll sprinkle in some free RAM upgrades to people who made 0 tickets, 0 comments with their ticket ID, etc, since we have so much extra. I already regret saying that because the people that made the most tickets are probably going to start making tickets asking for free RAM now.
Here are the current RAM usage levels for Tokyo:
TYOC034: 58GB/128GB
TYOC035: 46.9GB/128GB
TYOC036: 58.4GB/128GB
TYOC037: 42.8GB/128GB
TYOC038: 44.4GB/128GB
TYOC039: 74.2GB/128GB
TYOC040: 43.6GB/128GB
TYOC033: 54GB/128GB
This is actual used RAM. The "usage" number is higher by a little bit when you add in inactive/buffer/cache but that's just how Linux works. We're also not aggressively swapping.
How memory works:
It's not that the node is running out of RAM, it just decides to kill your process if you force it to use more memory than you're allocated. I believe it gives you some leeway and then when you super max it out, so around 440MB for 384MB plans, it kills your process and throws OOM errors. It simulates running out of memory.
Otherwise everyone could just use however much memory they want and people would take advantage of that. I think on OpenVZ this did happen to some degree with at least swap space and depending on how you set up settings, maybe for OpenVZ6 but I barely remember. Since that wasn't full virtualization.
It's kind of like how you can max out your CPU and essentially freeze up your VM although I do not know if that will crash as quickly, instead of it allowing you to just use as much of the node's CPU you want.
Some good news I was about to provide, which relates to the above.
We were super aggressive with our RAM calculations. So far, every single case has proven to be much lower than our calculations, by about 50%... this means since RAM was our bottleneck, we can probably easily fit in 20% more people per node, which will naturally speed up migrations by 20% and ensure everyone can pretty much land on a Ryzen. But don't quote me on this or be mad at me if I'm wrong. Don't get your hopes up, please. I'm just really excited and wanted to share the news.
Edit: PS if the node ever nodes out of memory like that, it'll just fully break from my understanding although I've never done that on purpose (and don't know how it actually happens from experience.) Maybe the node fully locks up or crashes, or maybe mass crashing of VMs?
From my experience debugging customers' VMs in the past, it's not usually only the RAM that does it. Maybe it's a combination of RAM and CPU. Because the CPU is required to swap out RAM, and if the CPU is also maxing out, it can't properly swap, and it's also running out of memory too, and it reaches the memory limit and crashes (gets killed.)
Edit -- One situation that this could definitely happen in is the situation it mostly gets done in which also confuses users the most which is on yum updates and things like that, or even auto updating OS where customer will think he template is broken. This is what I usually end up arguing once in a while in a super long ticket with customers where in the end I just double their RAM temporarily and it fixes everything, so they can do their updates and stop blaming us, and then I change it back.
with all due respect sir. no offense, instead on replying and wasting your time composing to those none sensible post of them, could you please please concentrate on the remaining activations. thanks 🙏
did someone say RAM?
Does this mean that the activation process stops when it reaches 67%, and when is the next time to activate the remaining 33%?
Go back to sleep; you're talking nonsense.
I am sure the information you want to know is on this page, but in any case, I suggest you get a good sleep and read it again.
https://virmach.com/ryzen-special-offer-news-updates/
I have an old 384 idle VPS... Installed Debian 11 with netboot.xyz and low memory warning (some manual modules to load):
RAM+SWAP:
Bench:
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
Yet-Another-Bench-Script
v2022-02-18
https://github.com/masonr/yet-another-bench-script
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
Tue Apr 12 11:47:30 -05 2022
Basic System Information:
Processor : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
CPU cores : 1 @ 2499.998 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM : 347.2 MiB
Swap : 523.0 MiB
Disk : 14.2 GiB
fio Disk Speed Tests (Mixed R/W 50/50):
iperf3 Network Speed Tests (IPv4):
Provider | Location (Link) | Send Speed | Recv Speed
| | |
Clouvider | London, UK (10G) | 1.37 Gbits/sec | 552 Mbits/sec
Online.net | Paris, FR (10G) | 1.48 Gbits/sec | 697 Mbits/sec
WorldStream | The Netherlands (10G) | 1.27 Gbits/sec | 346 Mbits/sec
WebHorizon | Singapore (400M) | busy | 289 Mbits/sec
Clouvider | NYC, NY, US (10G) | 4.26 Gbits/sec | 1.43 Gbits/sec
Velocity Online | Tallahassee, FL, US (10G) | 1.90 Gbits/sec | 1.27 Gbits/sec
Clouvider | Los Angeles, CA, US (10G) | 1.49 Gbits/sec | 431 Mbits/sec
Iveloz Telecom | Sao Paulo, BR (2G) | busy | busy
Yes but only until someone asks me to stop wasting time activating orders and concentrate on answering their ticket. And I'll only do their ticket until someone asks me to stop wasting time on that and instead focus on sending out their storage server. But I won't be caught doing that if someone asks me to instead focus on sending out Ryzen to another location, but only if someone doesn't ask me about Atlanta. And everyone better hope no one asks me to focus on E3 dedicated servers.
Oh by the way I already said some time ago, activations are automated now so I'm not even the one working on those right now.
Got it,gain some knowleadge. Now I knew how to count available services in one AMD node. As status, the rest 1/3 can be easily activated.
Are storage services going to activate in nodes above or they have storage only nodes?
I know this is a newbie question, but is it normal to see connections with IPs other than mine when I run
iftop -nP?For example, I see like
aaa.bbb.cccc.100:redisoraaa.bbb.ccc.249:ms-wbt-serverwhen my IP isaaa.bbb.cccc.ddd.And they are connected with, for example, the IP of Digital Ocean.
(Yes, I understand that those are port scans, etc. via VPN)
The unusual persistent downloading continues, reaching several GB of traffic since the last OS reinstallation about a couple of hours ago while my VM is just idle in node tokyo039.Am I the only one experiencing this problem?
@tototo
Yes.
So do basic sysadmin work.
Reinstall. Lock down ssh with key only access and port change. Install CSF.
And I think it has nothing to do with the so-called "public scan", because I have changed the ssh port and turned on the firewall and after iftop analysising,I found that the traffic maybe intranet traffic, always a fixed value for a small period of time.
Believe me, I did everything I had to do, reinstalled the system several times, closed all ports except ssh, and even restricted ssh can only connect to my one ip only, but the problem still exist. The traffic is always a fixed number about 500kbs,no more and no less. It drive me crazy! I know I'm not the only one facing this problem, can anyone else tell me about your situation?
The OS was reinstalled about 6 hours ago and the VM has been kept completely idle, but this is what is happening now. Every once in a while the traffic stats on solusvm increase. I swear to god something wrong is definitely going on here!