One of CTs not showing I/O Info

M

Michal Unzeitig

New Member
Oct 29, 2017
6
0
1
43
www.artio.net
Running proxmox 5.1.
I have 4 CTs on one node, all of them running Ubuntu. One of this CT does not show I/O stats in Proxmox GUI, the other 3 do.
Any ideas what to check, what may be wrong?
 
did you upgrade recently and not restart the host/the ct after that ?
also, what storage type do you use?
 
Thanks for reply.
The node is freshly setup - last week.
2 of the CTs that are showing I/O fine were migrated from an older node (3.1).
2 other CTs are newly created at the node. For one of these I/O graph works, for other not. (both started from the same template, Ubuntu 16.04, same way)

All CTs are using local storage directly on the node. (Type: LVM-Thin)

I believe the CT with issues was restarted couple times after installation. The node has not been restarted after the CTs were started, as they are production ones.
 
can you post the ouptut of
Code: 
pct status <VMID> --verbose
for a working and the non-working container?
 
Sure.

Problematic one:
Code: 
# pct status 100 --verbose
cpu: 0
cpus: 10
disk: 35379212288
diskread: 377593856
diskwrite: 0
lock:
maxdisk: 84014424064
maxmem: 21474836480
maxswap: 4294967296
mem: 10847776768
name: xxx
netin: 237837656180
netout: 1584474138588
pid: 9194
status: running
swap: 22663168
template:
type: lxc
uptime: 736892

Functional one:
Code: 
# pct status 107 --verbose
cpu: 0
cpus: 6
disk: 68968427520
diskread: 23234039808
diskwrite: 21639180288
lock:
maxdisk: 78729973760
maxmem: 12884901888
maxswap: 4294967296
mem: 990679040
name: yyy
netin: 82047772790
netout: 48029088760
pid: 19301
status: running
swap: 0
template:
type: lxc
uptime: 204737

Looks like the "diskwrite: 0" in the first case might be pointing on the issue. The question is why.
 
Last edited:
can you also post the ouptut of
Code: 
cat /sys/fs/cgroup/blkio/lxc/<VMID>/ns/blkio.throttle.io_service_bytes

or if it is an unprivileged one
Code: 
cat /sys/fs/cgroup/blkio/lxc/<VMID>/blkio.throttle.io_service_bytes
 
Here it is:
Code: 
# cat /sys/fs/cgroup/blkio/lxc/100/ns/blkio.throttle.io_service_bytes
253:0 Read 0
253:0 Write 0
253:0 Sync 0
253:0 Async 0
253:0 Total 0
253:1 Read 12288
253:1 Write 0
253:1 Sync 12288
253:1 Async 0
253:1 Total 12288
8:0 Read 94404608
8:0 Write 0
8:0 Sync 94404608
8:0 Async 0
8:0 Total 94404608
253:3 Read 94392320
253:3 Write 0
253:3 Sync 94392320
253:3 Async 0
253:3 Total 94392320
253:4 Read 94392320
253:4 Write 0
253:4 Sync 94392320
253:4 Async 0
253:4 Total 94392320
253:6 Read 94392320
253:6 Write 0
253:6 Sync 94392320
253:6 Async 0
253:6 Total 94392320
Total 377593856
 
it seems your container does not write to its disk? at least not in the topmost cgroup.
is there anything which might create a subcgroup ? if yes this is normal, since those cgroup values are not recursive
 
Certainly the container is writing to to its disk.
There is an adjustment of limits for MySQL DB in /lib/systemd/system/mysql.service.
Could that be a reason?
Anyway, I have a feeling that the graph was not shown since the CT was started, even before change to the limits above.
 
anything writing in a sub cgroup will not get picked up sadly, but there is no good solution here at the moment
 
You must log in or register to reply here.
Top Bottom