Proxmox: SSH klíče a zápisy disku

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Mám pár dotazů k proxmox ve 9:
1. proč má root uživatel defaultně nějaký klíč v .ssh/authorized keys a kde se tam vzal. Změna: když jsem si toho prvně všiml, byl tam jeden řádek "ssh-rsa AAAA...GQQ== root@hostname" a zakomentoval ho. Nyní tam jsou 4. Ovšem datum změny odpovídá datum vzniku. nějaký měsíc zpět.
Obsah:

Kód: [Vybrat]

#? ssh-rsa AAA...MvRUbjRXGQQ== root@hostname
ssh-rsa AAA...2wX60KnWPHw==
ssh-rsa AAA...==
ssh-rsa AAA...MvRUbjRXGQQ== root@hostname

2. Pokud budu mít víc mašin,které propojim v síti, jak docílím, aby se mi ocitli všechny nody pod Dashboard? Co je potřeba udělat ,aby celé spřažení bylo vidět pod jednou kapotou?

3. Proč mi to žere  2GB zápisu na disk denně, když to nic nedělá? Je to standardní množství dat, co zapisuje plus mínus každá dstribuce Existuje nějaká optimalizace jako commit teimout nebo vcar log na tmpfs?

[Reklama]

[czmiho]

Ty klice pridava sam proxmox pro vnitrni potreby pve (migrace a dalsi operace v clusteru kdy jeden nod dela ssh na druhy)

Vytvoreni clusteru a pridani nodu viz https://pve.proxmox.com/wiki/Cluster_Manager

Nemam zadny nicnedelajici proxmox abych to mohl zmerit, ale asi to bude v norme. Zalezi i na souborovem systemu a raidlevelu, treba zfs raidz2 bude mit write multiplication klidne pres 6x u malych zapisu. Ciste ze zvedavosti - proc te 2GB/den trapi?

[RDa]

3. Proč mi to žere  2GB zápisu na disk denně, když to nic nedělá? Je to standardní množství dat, co zapisuje plus mínus každá dstribuce Existuje nějaká optimalizace jako commit teimout nebo vcar log na tmpfs?

Odkud pochazi ta metrika "2GB denne" ?

Trasovani I/O, pokud tedy nic jako bezet nema, bych resil skrze inotify - podival se, na co se saha.

Samozrejme to neodhali veci, ktere jsou otevreny trvale a pristupuje se do nich.. takze zde bud udelat diff z nejakeho skenu FS s atributy (rekurzivni ls -la?) pred a po jednom dni, nebo prozkoumat lsof.

Pokud jsou data zapsany (ne prepsany), tak je muzes odhalit i skrze snapshotovani a diff mezi nema.

Dej vedet jak to pokrocilo v tomto smeru a na co jsi prisel - co za zapisy stalo.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Jo, nenapsal jsem, jak jsem to měřil a sice iostat -h 30 ,zatím ne hlouběji ne . kacířská otázka, když tam neběží VM, inotify se probojuje až to LXCs?
Disková geometrie je úplně základní setup s jediným nvme diskem kde je  storage local(Directory, asi z root partition,který je ext) a local-data, žádný raidy ani cephy

Jsou tam 2 LXC, na které defacto nikdo nepřistupuje

Proč mě to trápí, že mi to připadá prostě nadměrné na to že ty kontájnery nic nedělají a taky  že ten zápis se děje defacto přes všechny lvm. (ačkoliv discard jen přes dm-1=root)

A nebo jsem zmlsaný tím, že RPI za 100 dní má iostat-h:
      tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn Device
     0,03         0,4k         0,3k       3,6G       2,3G mmcblk0
(tam docker ani LXC ani virtuály nejsou, ale router dns, dhcp a vše co jsem identifikoval jako zapisující jsem montnul to tmpfs v fstab : varlolg, var-lib, varlata, var-cache-samba ,vařkaši, varkaše-nscd)   


A asi by to mělo vydržet 150let tímto tempem..... Jen si říkám, jestli to nezapisuje úplně zbytečně kvůli nějaké drobnosti jako  atime režim commit timeout, něco nad LVM...

Kód: [Vybrat]

#mapování:
 ls -lolgha /dev/mapper/ | grep -Pio pve-.+ |  awk '{ print $3 , $1}' |sort
../dm-0 pve-swap
../dm-1 pve-root
../dm-2 pve-data_tmeta
../dm-3 pve-data_tdata
../dm-4 pve-data-tpool
../dm-5 pve-data
../dm-6 pve-vm--100--disk--0
../dm-7 pve-vm--102--disk--0

iostat h 30 #  zajímavost  sloupec discard nuly kromě dm-1

Linux 6.14.11-3-pve (virt)      17.11.2025      _x86_64_        (4 CPU)

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
     0,00         0,0k         0,0k         0,0k       2,7M       0,0k       0,0k dm-0
     1,35         1,1k        11,4k       144,8k     677,5M       6,9G      88,0G dm-1
     0,02         0,0k         0,0k         0,0k      14,8M      30,0M       0,0k dm-2
     1,96         2,0k        11,6k         0,0k       1,2G       7,0G       0,0k dm-3
     1,96         2,0k        11,6k         0,0k       1,2G       7,0G       0,0k dm-4
     1,41         1,3k         8,6k         0,0k     807,0M       5,2G       0,0k dm-6
     0,55         0,7k         2,9k         0,0k     463,5M       1,7G       0,0k dm-7
     2,66        54,4k        23,0k       146,4k      33,1G      14,0G      89,0G nvme0n1

^ první výpis není aktivita za x sekund , ale od počátku (asi od bootu)
... uptime je 7 dní

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-0
     0,56         0,0k         1,8k         0,0k       0,0k      60,0k       0,0k dm-1
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-2
     1,94         0,0k         9,9k         0,0k       0,0k     336,0k       0,0k dm-3
     1,94         0,0k         9,9k         0,0k       0,0k     336,0k       0,0k dm-4
     1,59         0,0k         8,5k         0,0k       0,0k     288,0k       0,0k dm-6
     0,35         0,0k         1,4k         0,0k       0,0k      48,0k       0,0k dm-7
     2,00        45,2k        11,6k         0,0k       1,5M     396,0k       0,0k nvme0n1

lol

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-0
     1,41         0,0k        15,1k         0,0k       0,0k     512,0k       0,0k dm-1
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-2
     1,85         0,0k         8,1k         0,0k       0,0k     276,0k       0,0k dm-3
     1,85         0,0k         8,1k         0,0k       0,0k     276,0k       0,0k dm-4
     1,21         0,0k         5,8k         0,0k       0,0k     196,0k       0,0k dm-6
     0,65         0,0k         2,4k         0,0k       0,0k      80,0k       0,0k dm-7
     2,74        45,2k        23,2k         0,0k       1,5M     788,0k       0,0k nvme0n1

^C


[František Ryšánek]

apt-get install iotop ?
Jinak je to nějakých 24 kBps ... jestli atime by tomu mohl přidávat, inu proč ne... rostou nějaké logy? dmesg se pohybuje? Kdyby tam byl třeba ZFS, ten si téměř neustále na pozadí odmocňuje pí jenom z toho titulu že dejchá, ale EXT4 takové věci nedělá...

[Reklama]

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Pochopil jsem 24k * 86400.  , ještě jsem koukal Namespace 1 Formatted LBA Size:     4096, Maximum Data Transfer Size:         256 Pages
UPTIME 9 dní, 130GB. Dmesg má mrzkých 100kB od začátku, produkuje asi 5 řádek denně. mohl by to být swap, tuto neřest jsem tam aktivoval. Sice dm-0 je nula nula nula, ale možná na něm iostat není akurátní, když jde o swap.

var/log má 300MB , journal/ 301MB, ale s dnešnim datem 8 a 24 MB + 5x 8MB s dnešnim datem s tildou na konci, tudíž bych to viděl na maximálně 24 MB denně...


mount:
/dev/pve/root / ext4 errors=remount-ro 0 1 (realita  (rw,relatime,errors=remount-ro))
UUID=44SS-1944 /boot/efi vfat defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0


tune2fs -l /dev/pve/root
Lifetime writes:          41 GB
Last write time:          Tue Nov 18 15:14:14 2025 (6 minut nazad)
lock size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512

Zkusim mount option commit_timeout zvýšit z defaultních 5s...

[František Ryšánek]

Co ten iotop?
Ten by měl ukázat seznam procesů, seřazený podle generovných iops...

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Tady,, spouštěl jsem ho s delay 10s, asi po dobu minutu 3minut, podle procesů, accumulated

Kód: [Vybrat]

otal DISK READ:         0.00 B/s | Total DISK WRITE:         8.47 K/s
Current DISK READ:      50.99 K/s | Current DISK WRITE:       7.17 K/s
    PID  PRIO  USER     DISK READ DISK WRITE>    COMMAND                                                                                                                         
    946 be/4 root          0.00 B   1472.00 K pmxcfs
   4018 be/4 100999        0.00 B    732.00 K postgres: stats collector
   3030 be/3 root          0.00 B    292.00 K [jbd2/dm-6-8]
    267 be/3 root          0.00 B    232.00 K [jbd2/dm-1-8]
    319 be/4 root          0.00 B    124.00 K systemd-journald
    679 be/4 root          0.00 B    120.00 K rrdcached -g
   3982 be/3 root          0.00 B     52.00 K [jbd2/dm-7-8]
   4290 be/4 100000        0.00 B     48.00 K python3 /usr/bin/fail2ban-server -xf start
 158389 be/4 100033        0.00 B      8.00 K apache2 -k start
   1178 be/4 root          0.00 B      5.00 K pve-ha-lrm
   3312 be/4 100000        0.00 B      4.00 K dockerd -H fd:// --containerd=/run/containerd/containerd.sock
      1 be/4 root          0.00 B      0.00 B init

 -- zbytek jsou už bajty --
CONFIG_TASK_DELAY_ACCT and kernel.task_delayacct sysctl not enabled in kernel, cannot determine SWAPIN and IO %

pmxcfs by měl být proxmox cluster filesystem. Mám jen jedináčka v datacentru . file system for storing configuration files, replicated in real time to all cluster nodes using corosync.
       We use this to store all Proxmox VE related configuration files.

Mimochodem, proč pct exec trvá tak dlouho?

Kód: [Vybrat]

time pct exec 100 uname  #smezerou
Linux
real 0m0,718s
time lxc-attach 100 uname  #spomlčkou
Linux
real 0m0,017s

Toto mi ukazuje lxc-top

Kód: [Vybrat]

Container                   CPU          CPU          CPU                                BlkIO        Mem
Name                       Used          Sys         User                    Total(Read/Write)       Used
100                        0.00         0.00         0.00   0.00   (3182527929.78 GiB/2740693.74 GiB)    0.00   
102                        0.00         0.00         0.00    96.00   (122170.24 GiB/ 64.00   )    0.00   
TOTAL 2 of 2               0.00         0.00         0.00  96.00   (3182650100.03 GiB/2740693.74 GiB)    0.00 

Aspoň jsem přitom naučil double penetraci :
lxc-attach 100 -- docker exec compost1-database-1  cat /etc/postgresql/postgresql.conf

Kód: [Vybrat]

include_if_exists '/var/lib/postgresql/data/postgresql.conf'

shared_preload_libraries = 'vchord.so, vectors.so'
search_path = '"$user", public, vectors'
max_wal_size = 5GB
shared_buffers = 512MB
wal_compression = on
work_mem = 16MB
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_scale_factor = 0.05
autovacuum_vacuum_cost_limit = 1000
effective_io_concurrency = 200
random_page_cost = 1.2

include_if_exists '/var/lib/postgresql/data/postgresql.override.conf'

[František Ryšánek]

Aspoň jsem přitom naučil double penetraci :
lxc-attach 100 -- docker exec compost1-database-1  cat /etc/postgresql/postgresql.conf

:-D Vysvětluju si to správně?
V běžícím LXC s ID=100 uvnitř napíchni běžící instanci dockeru (známou jako compost1-database-1) a v ní proveď výpis textového souboru postgresql.conf

Dík, může se hodit.

(Příběh: před dávnými časy, v daleké galaxii, bylo nebylo, admin jednooký mezi slepými králem, zprovoznil si první ostrý Proxmox. Zjistil, že umí tlusté VM pomocí QEMU-KVM a štíhlé kontejnery pomocí LXC. A první užitečné zadání znělo, od kolegy: "Hele koukej jakou jsem našel boží hračku! Už jsem si ji stáhl! Ten download je ve formátu 'docker kontejner' no jak říkám, úplně boží - že mi ji hned ostře rozjedeš na tom tvém ostrém Proxmoxu! To je úžasné, jak je to IT dneska jednoduché!" :-D   Zjevně nejsem sám. Zmínky o dockeru v Proxmoxu potkávám zleva i zprava.)

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Jo, to je ono.  Další metrika:  while true;do smartctl -x ;sleep 50;done Write commands rostou rychlostí 2/sekundu ( 900/500s) a read commands 0.4/sekundu

[CFM]

Pokud není potřeba HA, tak nějaké zápisy ušetří vypnutí (vyzkoušeno na v8):

Kód: [Vybrat]

systemctl stop pve-ha-lrm
systemctl disable pve-ha-lrm
systemctl stop pve-ha-crm
systemctl disable pve-ha-crm
systemctl stop corosync.service
systemctl disable corosync.service


[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Uvidím, co je příčina, mám 4 kandidáty, zvýšit  commit u /  na commit=60* ; ty2služby deaktivovat(třetí není spuštěna- inactive=dead : nesplněna podmínka /etc/corosync.conf) ; zastavit docker container s tím postgresql (zapomněl jsem výrazně zmínit že ten proces běží uvnitř lxc uvnitř  dockeru)
*to není kandidát v pravém smyslu, něco jako Babiš Pavel Sládek

a taky monitorovat tune2fs -l  |grep -Pi lifetime\ ?writes
Potíž asi bude v tom že zápisy přes iotop, zápisy přes iostat  a následně totalhost writes (i kdyby integrované* block size) a nemusí odpovídat  kvůli všejakému cachování, commitu, journálům a mezivrstvě LVM.

[Docent Chocholoušek]

mám 4 kandidáty

No, já mám jednoho... ale nezoufej, je to řešitelné ústavní léčbou v zařízení s velkou zahradou.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

k té pgsql: BTW jsou tyhle výplody AI pravda?  (myslím hlavně ty názvy, konfig volby). Neorientuji se v ladění parametrů (Postgres natož)SQL a AI dokáže poradit i systemctl start pravevymyslenynazev sluzby nebo echo 1 : /sys/kernel/randomobama
Statistics Files: The stats collector writes data to statistics files (e.g., pg_statistic, pg_stat_io), which can lead to periodic disk writes.
Adjust Stats Frequency: Modify parameters like track_counts or track_io_timing to tune how much data is collected based on your needs.
ale:

Kód: [Vybrat]

track_activities = off
track_counts = offdata_directory = '/mnt/ramdisk/pgdata

track_counts = on  # or off, as needed
stats_temp_directory = '/mnt/ramdisk/pg_stat_tmp'
Reduce Stats Frequency:
Adjust related settings such as:
stats_row_level = off  # Reduces the statistical overhead

kanditáty na pacienty, na ředitele nebo na léčitele?