Howdy, Stranger!

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


Oracle Cloud Free Tier - Page 48
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.

Oracle Cloud Free Tier

1454648505164

Comments

  • phucvandinhphucvandinh Member
    edited August 2022

    Testing the AMD instance and it's very slow.

  • @phucvandinh said:
    Testing the AMD instance and it's very slow.

    That's what 1/8th of a core gets you

  • @MallocVoidstar said:

    @phucvandinh said:
    Testing the AMD instance and it's very slow.

    That's what 1/8th of a core gets you

    Taking million years to install something :neutral: I just then create an ARM instance with all storage space

  • ralfralf Member

    Yeah, I didn't even bother with free x86 instances because they sounded so poor, although I guess it might be worth using just to stick haproxy on there to forward to the other two machines.

  • @ralf said:
    Yeah, I didn't even bother with free x86 instances because they sounded so poor, although I guess it might be worth using just to stick haproxy on there to forward to the other two machines.

    Creating a server will use at least 47GB of 200GB free and for me with that poor performace, that 50GB is wasted. So I create the ARM with 200GB

  • @martheen said:

    @alilet said: showing the machine has 2 cores and 680MB RAM

    From Oracle docs :

    1 OCPU on x86 CPU Architecture (AMD and Intel) = 2 vCPUs

    While it's expected that certain amount of RAM to be reserved, over 300 MB seems excessive. What do you get when running https://github.com/madrisan/linux-iomem/blob/master/iomem.sh ?

    About the slow part, you don't actually get the entire OCPU, just 1/8 OCPU, as in, throttled to 12.5%

    [opc@instance-20220804-1531 ~]$ sudo ./linux-iomem.sh
    0 to 4095 bytes (0 to 0 Mb) - Reserved
    4096 to 655359 bytes (0 to 0 Mb) - System RAM
    655360 to 786431 bytes (0 to 0 Mb) - PCI Bus 0000:00
    983040 to 1048575 bytes (0 to 0 Mb) - System ROM
    1048576 to 8388607 bytes (1 to 7 Mb) - System RAM
    8388608 to 8421375 bytes (8 to 8 Mb) - ACPI Non-volatile Storage
    8421376 to 8454143 bytes (8 to 8 Mb) - System RAM
    8454144 to 9437183 bytes (8 to 8 Mb) - ACPI Non-volatile Storage
    9437184 to 1043255319 bytes (9 to 994 Mb) - System RAM
    146800640 to 161485423 bytes (140 to 154 Mb) - Kernel code
    163577856 to 173932543 bytes (156 to 165 Mb) - Kernel rodata
    174063616 to 176360511 bytes (166 to 168 Mb) - Kernel data
    179310592 to 195035135 bytes (171 to 185 Mb) - Kernel bss
    710934528 to 1004535807 bytes (678 to 957 Mb) - Crash kernel
    1043255320 to 1043293271 bytes (994 to 994 Mb) - System RAM
    1043293272 to 1043603455 bytes (994 to 995 Mb) - System RAM
    1043603456 to 1043640319 bytes (995 to 995 Mb) - Reserved
    1043640320 to 1066332159 bytes (995 to 1016 Mb) - System RAM
    1066332160 to 1068953599 bytes (1016 to 1019 Mb) - Reserved
    1068953600 to 1069019135 bytes (1019 to 1019 Mb) - ACPI Tables
    1069019136 to 1069543423 bytes (1019 to 1019 Mb) - ACPI Non-volatile Storage
    1069543424 to 1072611327 bytes (1019 to 1022 Mb) - System RAM
    1072611328 to 1073151999 bytes (1022 to 1023 Mb) - Reserved
    1073152000 to 1073741823 bytes (1023 to 1023 Mb) - ACPI Non-volatile Storage
    1073741824 to 4273995775 bytes (1024 to 4075 Mb) - PCI Bus 0000:00
    2147483648 to 2164260863 bytes (2048 to 2063 Mb) - 0000:00:02.0
    2147483648 to 2164260863 bytes (2048 to 2063 Mb) - bochs-drm
    2164326400 to 2164330495 bytes (2064 to 2064 Mb) - 0000:00:04.0
    2164330496 to 2164334591 bytes (2064 to 2064 Mb) - 0000:00:03.0
    2164334592 to 2164338687 bytes (2064 to 2064 Mb) - 0000:00:02.0
    2164334592 to 2164338687 bytes (2064 to 2064 Mb) - bochs-drm
    4273995776 to 4273996799 bytes (4076 to 4076 Mb) - IOAPIC 0
    4275044352 to 4275045375 bytes (4077 to 4077 Mb) - HPET 0
    4275044352 to 4275045375 bytes (4077 to 4077 Mb) - PNP0103:00
    4276092928 to 4276097023 bytes (4078 to 4078 Mb) - Local APIC
    4290772992 to 4294967295 bytes (4092 to 4095 Mb) - Reserved
    34359738368 to 36507222015 bytes (32768 to 34815 Mb) - PCI Bus 0000:00
    34359738368 to 34359754751 bytes (32768 to 32768 Mb) - 0000:00:03.0
    34359738368 to 34359754751 bytes (32768 to 32768 Mb) - virtio-pci-modern
    34359754752 to 34359771135 bytes (32768 to 32768 Mb) - 0000:00:04.0
    34359754752 to 34359771135 bytes (32768 to 32768 Mb) - virtio-pci-modern
    
  • labraxlabrax Member
    edited August 2022

    is there anyone who successfully approved in singapore region, mine just no answer at all after couple tries

  • @alilet said: 9437184 to 1043255319 bytes (9 to 994 Mb) - System RAM

    Seems pretty normal. Try rebooting?

  • @labrax said:
    is there anyone who successfully approved in singapore region, mine just no answer at all after couple tries

    Nope, all my and my friends card got rejected.

  • @martheen said:

    @alilet said: 9437184 to 1043255319 bytes (9 to 994 Mb) - System RAM

    Seems pretty normal. Try rebooting?

    I restarted but same issue. Both top and htop are showing 680MB RAM.

  • @labrax said:
    is there anyone who successfully approved in singapore region, mine just no answer at all after couple tries

    @niranjan said:

    @labrax said:
    is there anyone who successfully approved in singapore region, mine just no answer at all after couple tries

    Nope, all my and my friends card got rejected.

    That's weird! I got the Singapore region a few days ago with one trial

  • rm_rm_ IPv6 Advocate, Veteran

    No, that is not the case here. If you look closely at the screenshot, it says total ram is actually 680MB, not total is 1024 MB but "oh so much is taken (for disk caching)", as in the case which that website ridicules.

    As for the actual cause, I suspect this is how the effect of virtio-balloon might look like, which is a symptom of the host node running out of RAM.

  • xaocxaoc Member

    @rm_ said:

    No, that is not the case here. If you look closely at the screenshot, it says total ram is actually 680MB, not total is 1024 MB but "oh so much is taken (for disk caching)", as in the case which that website ridicules.

    As for the actual cause, I suspect this is how the effect of virtio-balloon might look like, which is a symptom of the host node running out of RAM.

    Oh, sorry, I misread the thingy, thought the 680MB was the RAM that was being used and not max RAM. xD

    I noticed different RAM values while testing different linux flavors on Oracle, was the same thing with OVH, I had about 1.7GB RAM instead of 2 on centos and it went to 1.9~ after installing debian.

  • miaumiau Member
    edited August 2022

    @phucvandinh said:

    @ralf said:
    Yeah, I didn't even bother with free x86 instances because they sounded so poor, although I guess it might be worth using just to stick haproxy on there to forward to the other two machines.

    Creating a server will use at least 47GB of 200GB free and for me with that poor performace, that 50GB is wasted. So I create the ARM with 200GB

    You can recover around 10gb by deleting ocivolume-oled partition that you dont normally use as LE user (and expand the root).

  • miaumiau Member
    edited August 2022

    @xaoc said:

    @rm_ said:

    No, that is not the case here. If you look closely at the screenshot, it says total ram is actually 680MB, not total is 1024 MB but "oh so much is taken (for disk caching)", as in the case which that website ridicules.

    As for the actual cause, I suspect this is how the effect of virtio-balloon might look like, which is a symptom of the host node running out of RAM.

    Oh, sorry, I misread the thingy, thought the 680MB was the RAM that was being used and not max RAM. xD

    I noticed different RAM values while testing different linux flavors on Oracle, was the same thing with OVH, I had about 1.7GB RAM instead of 2 on centos and it went to 1.9~ after installing debian.

    RHEL based distro has kdump memory reserve enabled by default. This reserves around 300mb memory.
    Debian has this feature disabled by default.

    You can disable this and recover that amount of ram by setting crashkernel=no in grub config,

  • lordnascloudlordnascloud Member
    edited August 2022

    Hello, please now I using 30 days trial account. I have Always Free instance (Ampere, 4vcore, 24 gb ram, 200 gb uhd boot disc). So please will be my instance automatically terminate after trial period or will be continue in Always Free mode?
    Thank you
    Regards

  • @lordnascloud said:
    Hello, please now I using 30 days trial account. I have Always Free instance (Ampere, 4vcore, 24 gb ram, 200 gb uhd boot disc). So please will be my instance automatically terminate after trial period or will be continue in Always Free mode?
    Thank you
    Regards

    As long as all your usage is below the Always Free values, it will not be automatically terminated when you leave the free trial. I still recommend you make your own backups in case Oracle screws you over in another way however.

    To note, they did used to terminate instances after the free trial, but they do not anymore and the docs were updated to reflect such.

    Thanked by 1rm_
  • I just created Arm A1 instance with 4 cores and 24GB RAM but it doesn't say "Always Free" against its name like the other instance. Do I need to be afraid or or this normal?

    While creating instance it also asked about some boot volume or something and default value was 50GB which I changed to 200GB so may be this is why it is not always free?

    But that 200GB is nowhere to be seen.

    [opc@arm ~]$ df -H
    Filesystem                  Size  Used Avail Use% Mounted on
    devtmpfs                     13G     0   13G   0% /dev
    tmpfs                        13G     0   13G   0% /dev/shm
    tmpfs                        13G   26M   13G   1% /run
    tmpfs                        13G     0   13G   0% /sys/fs/cgroup
    /dev/mapper/ocivolume-root   39G   13G   26G  33% /
    /dev/mapper/ocivolume-oled   11G  110M   11G   2% /var/oled
    /dev/sda2                   1.1G  297M  767M  28% /boot
    /dev/sda1                   105M  6.2M   99M   6% /boot/efi
    tmpfs                       2.5G     0  2.5G   0% /run/user/0
    tmpfs                       2.5G     0  2.5G   0% /run/user/987
    tmpfs                       2.5G     0  2.5G   0% /run/user/1000
    
  • @miau said:

    @xaoc said:

    @rm_ said:

    No, that is not the case here. If you look closely at the screenshot, it says total ram is actually 680MB, not total is 1024 MB but "oh so much is taken (for disk caching)", as in the case which that website ridicules.

    As for the actual cause, I suspect this is how the effect of virtio-balloon might look like, which is a symptom of the host node running out of RAM.

    Oh, sorry, I misread the thingy, thought the 680MB was the RAM that was being used and not max RAM. xD

    I noticed different RAM values while testing different linux flavors on Oracle, was the same thing with OVH, I had about 1.7GB RAM instead of 2 on centos and it went to 1.9~ after installing debian.

    RHEL based distro has kdump memory reserve enabled by default. This reserves around 300mb memory.
    Debian has this feature disabled by default.

    You can disable this and recover that amount of ram by setting crashkernel=no in grub config,

    Didn't work. First I updated value from auto to no

    sudo nano /etc/default/grub

    As you can see in screenshot below the value has been changed to no

    Then I try to ran following command but it said command not found

    sudo update-grub

    Anyway I rebooted machine but RAM is still 680MB

  • @alilet said: I just created Arm A1 instance with 4 cores and 24GB RAM but it doesn't say "Always Free" against its name like the other instance. Do I need to be afraid or or this normal?

    Don't worry, this is normal

  • FatGrizzlyFatGrizzly Member, Host Rep

    @alilet said:
    I just created Arm A1 instance with 4 cores and 24GB RAM but it doesn't say "Always Free" against its name like the other instance. Do I need to be afraid or or this normal?

    While creating instance it also asked about some boot volume or something and default value was 50GB which I changed to 200GB so may be this is why it is not always free?

    But that 200GB is nowhere to be seen.

    [opc@arm ~]$ df -H
    Filesystem                  Size  Used Avail Use% Mounted on
    devtmpfs                     13G     0   13G   0% /dev
    tmpfs                        13G     0   13G   0% /dev/shm
    tmpfs                        13G   26M   13G   1% /run
    tmpfs                        13G     0   13G   0% /sys/fs/cgroup
    /dev/mapper/ocivolume-root   39G   13G   26G  33% /
    /dev/mapper/ocivolume-oled   11G  110M   11G   2% /var/oled
    /dev/sda2                   1.1G  297M  767M  28% /boot
    /dev/sda1                   105M  6.2M   99M   6% /boot/efi
    tmpfs                       2.5G     0  2.5G   0% /run/user/0
    tmpfs                       2.5G     0  2.5G   0% /run/user/987
    tmpfs                       2.5G     0  2.5G   0% /run/user/1000
    

    You didn't, double check.

    You have two instances, and the max storage you can assign per acc is 200GB. So it's technically impossible to have assigned 200GB to arm instance.

  • ralfralf Member

    @alilet said:
    Then I try to ran following command but it said command not found

    sudo update-grub

    Anyway I rebooted machine but RAM is still 680MB

    Not surprising nothing changed if you haven't actually run the correct command. I'm not sure what package you need if you're using RH.

  • FatGrizzlyFatGrizzly Member, Host Rep

    @ralf said:

    @alilet said:
    Then I try to ran following command but it said command not found

    sudo update-grub

    Anyway I rebooted machine but RAM is still 680MB

    Not surprising nothing changed if you haven't actually run the correct command. I'm not sure what package you need if you're using RH.

    iirc. Oracle messes/rapes your vps everytime with cloud-init.

    I might be wrong, been so long since i used OCI

  • @varwww said:
    Seems like they are terminating random people on the free tier again.

    The OP seems to have updated the blog post. Oracle contacted (phone call) him and restored his A/c after he created Hacker News thread. :smiley: It's similar to LET, how when you complain about low end VPS provider here, you get support.

  • miaumiau Member
    edited August 2022

    @alilet said:
    Didn't work. First I updated value from auto to no

    sudo nano /etc/default/grub

    As you can see in screenshot below the value has been changed to no

    Then I try to ran following command but it said command not found

    sudo update-grub

    Anyway I rebooted machine but RAM is still 680MB

    You just saved the config, but it's not committed into bootloader yet.

    Not sure which tutorial you did follow, but RHEL family does not use update-grub script.
    You are supposed to use
    grub2-mkconfig -o /boot/grub2/grub.cfg

    without crashkernel you should have 962mb of total availabe memory

    Thanked by 1alilet
  • miaumiau Member
    edited August 2022

    @alilet said:
    I just created Arm A1 instance with 4 cores and 24GB RAM but it doesn't say "Always Free" against its name like the other instance. Do I need to be afraid or or this normal?

    While creating instance it also asked about some boot volume or something and default value was 50GB which I changed to 200GB so may be this is why it is not always free?

    But that 200GB is nowhere to be seen.

    [opc@arm ~]$ df -H
    Filesystem                  Size  Used Avail Use% Mounted on
    devtmpfs                     13G     0   13G   0% /dev
    tmpfs                        13G     0   13G   0% /dev/shm
    tmpfs                        13G   26M   13G   1% /run
    tmpfs                        13G     0   13G   0% /sys/fs/cgroup
    /dev/mapper/ocivolume-root   39G   13G   26G  33% /
    /dev/mapper/ocivolume-oled   11G  110M   11G   2% /var/oled
    /dev/sda2                   1.1G  297M  767M  28% /boot
    /dev/sda1                   105M  6.2M   99M   6% /boot/efi
    tmpfs                       2.5G     0  2.5G   0% /run/user/0
    tmpfs                       2.5G     0  2.5G   0% /run/user/987
    tmpfs                       2.5G     0  2.5G   0% /run/user/1000
    

    iirc in some condition the disk is not automatically partitioned into fs

    you have to invoke /usr/libexec/oci-growfs to expand it manually (this is the easy way, not sure about non-OL distro tho).

    edit: actually this is the defaut behavior (50gb root) according to docs

    By default, a boot volume for a compute instance extends only to 50 GB, which is the default minimum size. If a compute instance is created with a boot volume that is greater than or equal to 50 GB, the instance does not automatically use the entire volume. Use the oci-growfs utility to expand the root partition to fully utilize the allocated boot volume size. When the partition already extends to the entire volume, no changes are made to the system when using the utility.

    https://docs.oracle.com/en-us/iaas/oracle-linux/oci-utils/index.htm#oci-growfs

    Thanked by 1alilet
  • rm_rm_ IPv6 Advocate, Veteran
    edited August 2022

    @alilet said: While creating instance it also asked about some boot volume or something and default value was 50GB which I changed to 200GB so may be this is why it is not always free?

    First, the ARM instances never show "Always Free", this is normal.

    But if you are still within the first 30 days of trial, it is possible to overshoot the always free usage, e.g. by using too much storage. So double-check what it says in the panel, if actually claims to be 200 GB, then better delete and recreate to a lower size.

    Or delete all other VPSes and then it is okay to use 200 GB on this single one.

  • well, my vm is finally terminated few days ago, along with this email i received

    Your Oracle Cloud Free Trial expired on Friday, August 5, 2022 4:15 a.m. Coordinated Universal Time (UTC).
    
    Your access is limited to Always Free Services only. Your Always Free resources will remain available to you as long as you actively use your account. Your other resources will be reclaimed unless you upgrade to a paid account.
    
    Upgrade to a paid account to have access to all Oracle Cloud Services, customer support and other benefits of a paid services. Oracle Cloud offers Pay As You Go billing.
    

    still can make new free instances tho, but i'm in no hurry, so..

  • @ElonBezos said:
    well, my vm is finally terminated few days ago, along with this email i received

    Your Oracle Cloud Free Trial expired on Friday, August 5, 2022 4:15 a.m. Coordinated Universal Time (UTC).

    Your access is limited to Always Free Services only. Your Always Free resources will remain available to you as long as you actively use your account. Your other resources will be reclaimed unless you upgrade to a paid account.

    Upgrade to a paid account to have access to all Oracle Cloud Services, customer support and other benefits of a paid services. Oracle Cloud offers Pay As You Go billing.

    still can make new free instances tho, but i'm in no hurry, so..

    Your Always Free resources will remain available to you as long as you actively use your account

    Do we know what constitutes an active user? Like if we need to login to Oracle Cloud every 30 days to consider it active?

Sign In or Register to comment.