Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


VPS going down for unknown reason related to RAM - Page 2
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.

VPS going down for unknown reason related to RAM

2»

Comments

  • @jimaek said:
    If anyone cares the problem continues.

    https://dl.dropboxusercontent.com/s/8bu6p9ig92wfpgv/chrome_2016-12-19_15-16-40.png

    If someone has any ideas on what exactly it may be please let me know.

    Just ask the provider to destroy your container and recreate it manually from SolusVM admin?

  • This is totally an overselling issue. Paxhosting is having the exact same symptoms right now.

  • Bad memory module on host node maybe?

  • PieHasBeenEatenPieHasBeenEaten Member, Host Rep

    @stefeman please explain how you know this overselling? Do you have root access to the node? Do you know how much memory and diskspace is in use and free? Just because it smells like a pig doesn't mean its a pig.

  • @PieNotEvenEaten said:
    Just because it smells like a pig doesn't mean its a pig.

    Now I'm curious. What smells like a pig but not a pig? Please provide examples.

  • PieHasBeenEatenPieHasBeenEaten Member, Host Rep

    @yura i smell like a pig but im not a pig.

  • @PieNotEvenEaten said:
    @yura i smell like a pig but im not a pig.

    And how do we know that?

    Thanked by 2Yura Dumbledore
  • @PieNotEvenEaten said:
    @yura i smell like a pig but im not a pig.

    Personal anecdotes are hardly a convincing evidence. But I appreciate your honesty and personal story.

    Thanked by 1deadbeef
  • stefemanstefeman Member
    edited December 2016

    @PieNotEvenEaten said:

    @stefeman please explain how you know this overselling? Do you have root access to the node? Do you know how much memory and diskspace is in use and free? Just because it smells like a pig doesn't mean its a pig.

    If you balloon the memory on host node and peak load > RAM capacity, VM's will go down randomly and the end user machines will receive allocation errors. As for why I suspect this to be the case, is because i've done this disgraceful thing called "overloading" myself when aiming for better profits lol. Though what I resold was a 29€/m E3 dedi from online.net via hackforums. A typical summerhost one might say.. Not long after I ran out of users and refunded the remaining one and bailed, but it was a worthy experience.

    Thanked by 1deadbeef
  • @stefeman said:
    This is totally an overselling issue. Paxhosting is having the exact same symptoms right now.

    Did you purchase from Paxhosting? Aren't they the guys that @gcat made a post about?

  • jarjar Patron Provider, Top Host, Veteran
    edited December 2016

    After reading this thread it seems weird to me that no one has suggested this possibility:

    That the VM is running out of memory and the host is not graphing the memory usage correctly.

    Someone care to fill me in on why this isn't the default assumption? Graphs, especially in solusvm, are not perfect. A VM running out of memory is usually just that...a VM running out of memory.

    The whole "it doesn't do this elsewhere" is an interesting thing to note but it's not a valid point when used to draw the conclusion that it can't be what's happening here. If all servers worked 100% consistently the same or differences were clear and predictable, sysadmins would have less work to do.

  • not a blame post, actual help



    Write a simple C program that allocates some RAM every few seconds (I'm sure there are already programs that do this, just look it up on Google). Make sure there are messages showing how much memory is being allocated. Monitor the container and see if you're getting the same error messages you're getting it now. If you get those messages before your allocated memory then you should let your host know. You can also mount a part of your RAM as disk (ramdisk) and just put files in that mount point to see if you're getting expected behavior.

    Thanked by 1deadbeef
  • I created a ramdisk of 2GB and filled it. I was able to use 100% of RAM without crashing the server.

    Maybe I was lucky and if I repeat this test in 2 days it will crash. I will try to repeat it again when I can.

  • Nov 17 03:57:01 madrid-ginernet systemd[1]: Failed to create cgroup /user.slice/user-0.slice/session-159938525.scope: Cannot allocate memory
    Nov 17 03:57:01 madrid-ginernet systemd[1]: Failed to start Session 159938525 of user root.
    Nov 17 03:57:01 madrid-ginernet systemd-logind[113]: Failed to save session data /run/systemd/sessions/159938525: Cannot allocate memory
    Nov 17 03:57:01 madrid-ginernet systemd-logind[113]: Failed to save user data /run/systemd/users/0: Cannot allocate memory
    Nov 17 03:57:01 madrid-ginernet systemd-logind[113]: Failed to save session data /run/systemd/sessions/159938525: Cannot allocate memory
    Nov 17 03:57:01 madrid-ginernet crond[10235]: pam_systemd(crond:session): Failed to create session: Start job for unit session-159938525.scope failed with 'failed'
    

    Is it me, or is that session number -really- high.

    Thanked by 1doghouch
  • Amazing how many people blame the host and they do not show slightest doubt that some thing else might be wrong :)

    Thanked by 1jar
  • MaouniqueMaounique Host Rep, Veteran

    OVZ is a weird beast. It is a collection of patches stitched together with an unpredictible behaviour.
    We also had many problems with it until we understood that small containers in large numbers lead to many threads and soft lockups, crazy wa while iotop shows KBs and not MBs, however, such a problem i see for the first time.

    That does not mean it is impossible, we now have an issue with a KVM which locks up so badly that cannot be killed in any way, save for restarting the node. It happens only for that customer and only for that installation, even though he has multiple DNS servers with us. It also only happens in Debian installations on the node, not Centos or Ubuntu, after a few days trying to debug and 2 nodes restarts, we ended up giving him an IWStack instance when it locked the third time in another VM we gave as a replacement.
    In hundreds of nodes and thousands of customers, you should expect the unexpected, nobody can test al the combinations out there node and VM side.

    Thanked by 1vimalware
  • That's why I only do business with big companies

Sign In or Register to comment.