pgtable_alloc_virtual:103 Got addr 140312031141888 for size 4194304

[Максим Ткаленко (Unified Cloud System)]

Hi, when freshly installed on a machine with 48Gb of memory on CentOS 7 At the same time, the application takes up 32 Gb of memory. Does anyone know if this is normal or what to do to fix the problem.

in log  

Jan 18 17:33:38 ds-1 coredev: main:1544 pgtable init

Jan 18 17:33:38 ds-1 coredev: pgtable_init:161 Mem 50431660032 reserved 70 reserved mem 35302162000 count 8416
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312031141888 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312026947584 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312022753280 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312018558976 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312014364672 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312010170368 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312005976064 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140312001781760 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311997587456 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311993393152 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311989198848 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311985004544 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311980810240 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311976615936 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311972421632 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311968227328 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311964033024 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311959838720 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311955644416 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311951450112 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311947255808 for size 4194304
Jan 18 17:33:38 ds-1 coredev: pgtable_alloc_virtual:103 Got addr 140311943061504 for size 4194304

and so on

[QUADStor Support]

Hi,

This is normal. Upto 70% of the memory is initially reserved. It can go upto 80%.

--
You received this message because you are subscribed to the Google Groups "QUADStor Storage Virtualization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quadstor-vir...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quadstor-virt/2b4cf1f6-82f9-426b-a027-dd4ba067bb73n%40googlegroups.com.

[Максим Ткаленко (Unified Cloud System)]

this situation on release 3.2.22
I have another machine with CentOS 7 (Kernel 3.10.0-1160.81.1.el7.x86_64) and 16Gb Ram on it, and release 3.2.22 works for a maximum of half a day, then the application hangs and falls off from ESXi hosts.
but on this machine and release 3.2.19 there is no such problem.

Going back to the machine with 48GB of memory, isn't 32GB eaten up by quadstor-virt, while there is only 2Tb of disk space?

both of my machines have 2TB of disk space dedicated to quadstor-virt

четверг, 19 января 2023 г. в 01:45:20 UTC+3, quadstor:

[QUADStor Support]

Hi,

On Thu, Jan 19, 2023 at 5:30 PM Максим Ткаленко (Unified Cloud System) <tkale...@gmail.com> wrote:

this situation on release 3.2.22
I have another machine with CentOS 7 (Kernel 3.10.0-1160.81.1.el7.x86_64) and 16Gb Ram on it, and release 3.2.22 works for a maximum of half a day, then the application hangs and falls off from ESXi hosts.
but on this machine and release 3.2.19 there is no such problem.

 

Please send the logs from this machine (HTML UI > System Page > Run Diagnostics) to sup...@quadstor.com

 

Going back to the machine with 48GB of memory, isn't 32GB eaten up by quadstor-virt, while there is only 2Tb of disk space?

both of my machines have 2TB of disk space dedicated to quadstor-virt

 

16GB would have been allocated initially for deduplication tables and the memory usage over time would have grown easily to around 24 GB. Now we allocate more memory upfront which allows us to work with memory better.  The virtualization software is heavily dependent on memory, so any extra memory is always a help.  It's not dependent on the disk space configured. Yes if the configured disk is very large and memory is low then there will be a slow down in performance because we no longer can cached metadata as much as needed. But in the opposite case it should help with performance. 

To view this discussion on the web visit https://groups.google.com/d/msgid/quadstor-virt/dd19830a-6db6-4638-81a1-c0dc4fee16cen%40googlegroups.com.

[Максим Ткаленко (Unified Cloud System)]

Log, as requested, sent to sup...@quadstor.com

четверг, 19 января 2023 г. в 22:37:49 UTC+3, quadstor:

To unsubscribe from this group and stop receiving emails from it, send an email to quadstor-virt+unsubscribe@googlegroups.com.

[Максим Ткаленко (Unified Cloud System)]

Additional comment, the second day of uptime the application ate 40Gb, and already went to SWAP by 2Gb ..... but it does not hang, 54 VMs on 4 hosts feel good.

четверг, 19 января 2023 г. в 22:37:49 UTC+3, quadstor:

Hi,