Shrinkage!!!

edited August 2023 in Technical

So I've got a dirt cheap Black Friday VPS for a few years. Specs when purchased were 896MB ram.

After a year or so the ram being reported changed to 854MB but control panel still reported it was 896MB. A couple months later I opened a ticket - ticket was closed and a response from the provider seemed to indicate to me they were not happy about something - am guessing they were having a bad day.

A month or two ago the RAM dropped again now it's 837MB. The website I hosted on that site was having problems- sometimes MariaDB would crash from memory error, sometimes other things would crash and website would be offline for a couple days before I noticed. I ended up moving the site to a (cough cough) PlumFather VPS I use for backups, it's been running fine. It is just a hobby site at this point.

Question is this:

When purchased the VPS correctly reported 896MB, why might it drop to 856MB after a year or so and then drop again to 838MB? I do know that it's normal for the amount of "purchased" memory to differ from what your VPS will report. For example I have a 2GB RAM VPS and it reports 1.92GB.

What's correct and how are the reported RAM numbers being calculated?

Not going to name them or contact the provider about this again because they have been very generous to me, so in that respect this issue is trivial. Probably just won't renew this for another year come BF. But am curious about what's most likely going on with the RAM.

Perhaps :

?

Comments

  • FrankZFrankZ Moderator
    edited August 2023
    1. Most providers quote MB or GB in their memory specs, but most OS report MiB or GiB.
    2. If there was a upgrade of the OS, maybe crashkernel RAM usage changed. Disable crashkernel to get your RAM back.
    Thanked by (1)JDMcPea

    I am currently traveling in mostly remote areas until sometime in April 2024. Consequently DM's sent to me will go unanswered during this time.
    For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add

  • Ah, yes, that is very normal. Servers try to optimize the resources, so if the server feels that you are not using the full RAM allocated, they tend to reduce it so you only have what you need. That way others who need more RAM can get it :lol:

    Btw, you forgot to name and shame the provider :p

    Thanked by (1)JDMcPea

    Websites have ads, I have ad-blocker.

  • @FrankZ said:

    1. If there was a upgrade of the OS, maybe crashkernel RAM usage changed. Disable crashkernel to get your RAM back.

    Thanks FrankZ.

    OS is Debian 11. Tried the command: dmesg | Reserving - there is no output.

    cat /proc/cmdline returns BOOT_IMAGE=/boot/vmlinuz-5.10.0-23-amd64 root=UUID=0aa4a5a9-990e-48f0-9ec5-afc98

    So with my limited knowledge appears crashkernel is not the issue here.

  • @somik said:

    Btw, you forgot to name and shame the provider :p

    In this case it would be like shaming someone who declines to fix the bad brakes on your old car but gives you a new car for free :o

  • Try booting with iommu=off

    Thanked by (1)JDMcPea
  • @JDMcPea said: OS is Debian 11. Tried the command: dmesg | Reserving - there is no output.

    Has it always been 11 or was it originally 9 then 10 and then 11?

    Thanked by (1)JDMcPea
  • Ya know, memory is like yor sponge thingy, it shrinks over time

    Thanked by (1)JDMcPea

    smartass shitposting satirist

  • I also have experienced shrinkage but of a different variety... wonder if it is related

    Thanked by (1)JDMcPea

    Cheap dedis are my drug, and I'm too far gone to turn back.

  • @tetech said:
    Try booting with iommu=off

    My Debian 11 (fresh install, not upgraded) /etc/default/grub file looks like this:

    GRUB_DEFAULT=0
    GRUB_TIMEOUT=5
    GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian
    GRUB_CMDLINE_LINUX_DEFAULT="quiet"
    GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

    should I edit it to look like this:

    GRUB_DEFAULT=0
    GRUB_TIMEOUT=5
    GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian
    GRUB_CMDLINE_LINUX_DEFAULT="quiet"
    GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
    iommu=off

    or maybe:

    amd_iommu=off ? (it's a Ryzen CPU on the VPS)

    I booted to the System Rescue CD, started desktop, and it reports 864.76MB . Booted it again and ran MemTest86+ and it reports 895MB

    So it's looking like the provider is supplying the correct amount of RAM and just need to figure out where those sneaky MBs are hiding.

  • Someone is playing with the ram slider.
    Likely so you complain to him and he would have a reason to be very angry at you.
    I don't understand why people bare with shitty providers.

    Thanked by (1)JDMcPea
  • @Janevski said:
    Someone is playing with the ram slider.

    Am sure that is not the case because a clean boot to System Rescue CD and running MemTest86+ reports 895MB

    Booting to System Rescue CD and starting desktop reports reports 864.76MB

    Booting to Debian 11 reports 838MB in Virtualmin control panel, and I got the same when running YABS.

    Seems likely now it's something to do with the OS. What confused me is that when I first got the VPS it reported 896MB, it dropped after a year, and dropped again a couple months ago.

    There is a simple explanation somebody is gonna know, please share.

  • tetechtetech OG
    edited August 2023

    @JDMcPea said: GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
    iommu=off

    or maybe:

    amd_iommu=off ? (it's a Ryzen CPU on the VPS)

    It should be in the GRUB_CMDLINE_LINUX line, like GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 iommu=off"

    This affects some kernel versions, so no sure whether it is relevant to your current OS or not, but easy to try.

    @JDMcPea said: booted to the System Rescue CD, started desktop, and it reports 864.76MB . Booted it again and ran MemTest86+ and it reports 895MB

    I think by default you'll get 16MB reserved for VGA video console. I think the rest tends to be things like DMA buffers, but the earlier lines in dmesg should give the clues. I'm not an expert.

    Thanked by (1)JDMcPea
  • @Janevski said: I don't understand why people bare with shitty providers.

    People should bare with shitty providers!

    The all seeing eye sees everything...

  • @terrorgen said:

    @Janevski said: I don't understand why people bare with shitty providers.

    People should bare with shitty providers!

    Or at least exchange naked pictures

    Thanked by (1)terrorgen
  • @JDMcPea said:

    Or at least exchange naked pictures

    smartass shitposting satirist

Sign In or Register to comment.