[SOLVED] Performance Probleme / Ceph

Discussion in 'Proxmox VE (Deutsch)' started by norderstedt, Jan 11, 2019.

  1. norderstedt

    norderstedt Member

    Joined:
    Nov 28, 2016
    Messages:
    49
    Likes Received:
    2
    Moin!

    Wir betreiben einen großen CEPH / Proxmox Cluster und ich finde leider im Moment keinen Ansatz zur Problemlösung der Performanceprobleme. IOStat zeigt extrem hohe Auslastungen einzelner RBDs, wenn ich in einem Pool einen Ceph-Benchmark laufen lassen geht ein bestimmtes RBD an die Wand. Darum mal hier die Frage, ob vielleicht jemand einen Ansatz hat:

    Crushmap:

    Code:
    # begin crush map
    tunable choose_local_tries 0
    tunable choose_local_fallback_tries 0
    tunable choose_total_tries 50
    tunable chooseleaf_descend_once 1
    tunable chooseleaf_vary_r 1
    tunable chooseleaf_stable 1
    tunable straw_calc_version 1
    tunable allowed_bucket_algs 54
    
    # devices
    device 0 osd.0 class ssd
    device 1 osd.1 class ssd
    device 2 osd.2 class ssd
    device 3 osd.3 class ssd
    device 4 osd.4 class ssd
    device 5 osd.5 class ssd
    device 6 osd.6 class ssd
    device 7 osd.7 class ssd
    device 8 osd.8 class ssd
    device 9 osd.9 class ssd
    device 10 osd.10 class ssd
    device 11 osd.11 class ssd
    device 12 osd.12 class ssd
    device 13 osd.13 class ssd
    device 14 osd.14 class ssd
    device 15 osd.15 class ssd
    device 16 osd.16 class ssd
    device 17 osd.17 class ssd
    device 18 osd.18 class ssd
    device 19 osd.19 class ssd
    device 20 osd.20 class ssd
    device 21 osd.21 class ssd
    device 22 osd.22 class ssd
    device 23 osd.23 class ssd
    device 24 osd.24 class ssd
    device 25 osd.25 class ssd
    device 26 osd.26 class ssd
    device 27 osd.27 class ssd
    device 28 osd.28 class ssd
    device 29 osd.29 class ssd
    
    # types
    type 0 osd
    type 1 host
    type 2 chassis
    type 3 rack
    type 4 row
    type 5 pdu
    type 6 pod
    type 7 room
    type 8 datacenter
    type 9 region
    type 10 root
    
    # buckets
    host PX10-WW-SN03 {
        id -23        # do not change unnecessarily
        id -24 class ssd        # do not change unnecessarily
        # weight 2.912
        alg straw2
        hash 0    # rjenkins1
        item osd.22 weight 0.728
        item osd.23 weight 0.728
        item osd.24 weight 0.728
        item osd.25 weight 0.182
        item osd.26 weight 0.182
        item osd.27 weight 0.182
        item osd.28 weight 0.182
    }
    host PX10-WW-N04 {
        id -19        # do not change unnecessarily
        id -20 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.13 weight 0.728
    }
    host PX10-WW-N03 {
        id -17        # do not change unnecessarily
        id -18 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.12 weight 0.728
    }
    host PX10-WW-N05 {
        id -31        # do not change unnecessarily
        id -32 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.29 weight 0.728
    }
    datacenter WW {
        id -27        # do not change unnecessarily
        id -28 class ssd        # do not change unnecessarily
        # weight 5.094
        alg straw2
        hash 0    # rjenkins1
        item PX10-WW-SN03 weight 2.910
        item PX10-WW-N04 weight 0.728
        item PX10-WW-N03 weight 0.728
        item PX10-WW-N05 weight 0.728
    }
    host PX10-HBS-N03 {
        id -11        # do not change unnecessarily
        id -12 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.9 weight 0.728
    }
    host PX10-HBS-N04 {
        id -13        # do not change unnecessarily
        id -14 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.10 weight 0.728
    }
    host PX10-HBS-N05 {
        id -15        # do not change unnecessarily
        id -16 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.11 weight 0.728
    }
    host PX10-HBS-SN01 {
        id -21        # do not change unnecessarily
        id -22 class ssd        # do not change unnecessarily
        # weight 2.912
        alg straw2
        hash 0    # rjenkins1
        item osd.14 weight 0.728
        item osd.15 weight 0.728
        item osd.16 weight 0.728
        item osd.17 weight 0.182
        item osd.18 weight 0.182
        item osd.19 weight 0.182
        item osd.20 weight 0.182
    }
    datacenter HBS {
        id -25        # do not change unnecessarily
        id -30 class ssd        # do not change unnecessarily
        # weight 5.094
        alg straw2
        hash 0    # rjenkins1
        item PX10-HBS-N03 weight 0.728
        item PX10-HBS-N04 weight 0.728
        item PX10-HBS-N05 weight 0.728
        item PX10-HBS-SN01 weight 2.910
    }
    host PX10-BW-N03 {
        id -3        # do not change unnecessarily
        id -4 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.0 weight 0.728
    }
    host PX10-BW-N04 {
        id -5        # do not change unnecessarily
        id -6 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.1 weight 0.728
    }
    host PX10-BW-N05 {
        id -7        # do not change unnecessarily
        id -8 class ssd        # do not change unnecessarily
        # weight 0.728
        alg straw2
        hash 0    # rjenkins1
        item osd.2 weight 0.728
    }
    host PX10-BW-SN02 {
        id -9        # do not change unnecessarily
        id -10 class ssd        # do not change unnecessarily
        # weight 2.912
        alg straw2
        hash 0    # rjenkins1
        item osd.3 weight 0.728
        item osd.4 weight 0.728
        item osd.5 weight 0.728
        item osd.6 weight 0.182
        item osd.7 weight 0.182
        item osd.8 weight 0.182
        item osd.21 weight 0.182
    }
    datacenter BW {
        id -26        # do not change unnecessarily
        id -29 class ssd        # do not change unnecessarily
        # weight 5.094
        alg straw2
        hash 0    # rjenkins1
        item PX10-BW-N03 weight 0.728
        item PX10-BW-N04 weight 0.728
        item PX10-BW-N05 weight 0.728
        item PX10-BW-SN02 weight 2.910
    }
    root default {
        id -1        # do not change unnecessarily
        id -2 class ssd        # do not change unnecessarily
        # weight 15.282
        alg straw2
        hash 0    # rjenkins1
        item WW weight 5.094
        item HBS weight 5.094
        item BW weight 5.094
    }
    
    # rules
    rule replicated_rule {
        id 0
        type replicated
        min_size 1
        max_size 10
        step take default
        step chooseleaf firstn 0 type datacenter
        step emit
    }
    
    # end crush map
    IOStat auf einem der SQL-Nodes (rbd3 ist das SQL-Datastore für die Datenbank)

    Code:
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               1.35    0.00    2.28    0.25    0.00   96.11
    
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
    sdb               0.00    48.00    0.00  282.00     0.00  4504.00    31.94     0.05    0.17    0.00    0.17   0.10   2.80
    sdc               0.00     7.00    0.00    6.00     0.00    76.00    25.33     0.02    2.67    0.00    2.67   2.67   1.60
    dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
    dm-1              0.00     0.00    0.00   13.00     0.00    76.00    11.69     0.04    3.08    0.00    3.08   1.23   1.60
    dm-2              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
    rbd1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
    rbd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
    rbd2              0.00     0.00    0.00    1.00     0.00     4.00     8.00     0.00    0.00    0.00    0.00   0.00   0.00
    rbd3              0.00    24.00    1.00  172.00    16.00  5248.00    60.86     0.52    3.01    4.00    3.00   0.72  12.40
    rbd6              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
    
    Alle Nodes sind mit 800er Intel Datacenter-SSDs bestückt (und einigen 200ern). Die Verteilung seht ihr in der Crushmap. Wir replizieren 3fach, jeweils 1x pro Rechenzentrum.

    Wenn ich jetzt einen neuen Pool anlege und einen Benchmark laufen lassen, geht das rbd3 ebenfalls auf 100% usage hoch. Die anderen RBD-Volumes haben dieses Problem nicht. Vielleicht jemand eine Idee?

    Das Benchmark zeigt 700-900 MB/s (Megabyte/s) Schreibrate über alle 3 Rechenzentren. Also hier ist alles i.O.. Es ist derzeit ein Pool aktiv. Der Pool ist mit 1024 PGs angelegt (mit o.g. Replication-Rule).

    Das RBD3 zeigt 12% Utilisation an, /dev/sdb (ist das OSD auf dem Host) aber nur 3%. Auch habe ich 2-3ms write-wait auf dem RBD, aber nur 0.17ms auf /dev/sdb.
     
  2. sb-jw

    sb-jw Active Member

    Joined:
    Jan 23, 2018
    Messages:
    486
    Likes Received:
    42
    Hast du eine OSD die vielleicht nearfull ist? Wie sieht das ceph allgemein aus, ist es healthy?
     
  3. norderstedt

    norderstedt Member

    Joined:
    Nov 28, 2016
    Messages:
    49
    Likes Received:
    2
    Ceth ist 100% healthy, OSDs (SSDs) alle mit smartmontools überprüft, hier ein Screenshot von den OSDs

    [​IMG]
     
  4. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,186
    Likes Received:
    192
    Das könnte durch die Verteilung der OSDs kommen. Auch wenn auf Datacenter-Ebene die Replica stattfindet, die Gewichtung der Nodes in den Datacentern ist doch ungleich. Eine homogenere Verteilung der OSDs würde sich anbieten.

    Je nach SSD Performance sollte da mehr gehen. Die ~900 MB/s hören sich nach der Obergrenze von 10 GbE an.

    Ich nehme an Utilisation anstatt Usage?

    Wie ist die VM konfiguriert (qm config <vmid>)?

    EDIT: Wir haben letztes Jahr ein Ceph Benchmark Paper herausgebracht, das schon gesehen?
    https://forum.proxmox.com/threads/proxmox-ve-ceph-benchmark-2018-02.41761/
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. norderstedt

    norderstedt Member

    Joined:
    Nov 28, 2016
    Messages:
    49
    Likes Received:
    2
    Das lässt sich im Moment nicht besser realisieren. Die PGs werden ja dann auf Datacenter-Ebene verteilt, jede OSD ist hier gleich beansprucht, lediglich der "Flaschenhals" wäre der eine Server mit 6 statt einer Platte. Alle Server sind jedoch mit 10G angebunden und CPU-technisch gut ausgestattet, sollte hier kein Problem sein.

    Exakt, wir kommen hier an unsere Backbone-Grenze (rüsten derzeit auf 40G auf).

    Exakt.


    Sind LXC-Container.

    arch: amd64
    cores: 8
    cpuunits: 2048
    hostname: XXXXXXX
    memory: 8192
    mp0: PX-LIVE_ct:vm-1016-disk-1,mp=/database,size=20G
    nameserver: 172.xx.xx.xx
    net0: name=eth0,bridge=vmbr8,gw=172.xx.xx.xx,hwaddr=92:6E:02:04:B4:4F,ip=172.xx.xx.xx/24,type=veth
    net1: name=eth1,bridge=vmbr5,hwaddr=B2:0B:65:FB:16:25,ip=192.xx.xx.xx/24,type=veth
    onboot: 0
    ostype: centos
    rootfs: PX-LIVE_ct:vm-1016-disk-0,size=8G
    searchdomain: xxx.xxx.de
    swap: 0
    unprivileged: 1
    lxc.prlimit.nofile: 30000


    Das lässt sich im Moment nicht besser realisieren. Die PGs werden ja dann auf Datacenter-Ebene verteilt, jede OSD ist hier gleich beansprucht, lediglich der "Flaschenhals" wäre der eine Server mit 6 statt einer Platte. Alle Server sind jedoch mit 10G angebunden und CPU-technisch gut ausgestattet, sollte hier kein Problem sein.

    Exakt, wir kommen hier an unsere Backbone-Grenze (rüsten derzeit auf 40G auf).

    Exakt.


    Jep, gesehen.
     
  6. Knuuut

    Knuuut Member

    Joined:
    Jun 7, 2018
    Messages:
    88
    Likes Received:
    8
    Das kann ich aus eigener Erfahrung bestätigen. Nodes mit wenigen OSDs im Vergleich zu anderen Nodes können einen Cluster ganz schön ausbremsen.
    Schau doch mal mal nach auf welchen OSDs rbd3 verteilt ist und setze das in den Vergleich zu den anderen rbds, die das Problem nicht haben.
    Code:
    rbd info rbd3 -p <POOLNAME>
    rbd image 'rbd3':
            size xxx MB in xxxx objects
            order xx (xxxx kB objects)
            block_name_prefix: rbd_data.abcdefg123
            format: 2
            features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
            flags:
            create_timestamp: <DATE>
    Dann nimmst du den Wert von block_name_prefix und grepst danach:
    Code:
    rados -p >POOLNAME> ls | grep rbd_data.abcdefg123
    rbd_data.abcdefg123blablubb
    rbd_data.abcdefg123bla
    rbd_data.abcdefg123blubb
    
    Zu guter Letzt schaust du nach wo deine Objekte liegen
    Code:
    ceph osd map <POOLNAME> rbd_data.abcdefg123blablubb
    osdmap e15798 pool 'POOLNAME' (3) object 'rbd_data.abcdefg123blablubb.0000000000000c01' -> pg 3.9b654c27 (3.27) -> up ([3,4,11], p3) acting ([3,4,11], p3)
    
    wobei die Werte in up[x,y,z] die osd.x osd.y und osd.z sind

    Cheers Knuuut
     
  7. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,186
    Likes Received:
    192
    Genau, die Server mit den 7 SSDs bekommen mehr Traffic ab, da sie die höchste Gewichtung haben. Damit werden mehr PGs auf diesen Server geschrieben (und gelesen). Ein 'ceph osd df tree' sollte zeigen, wieviel PGs sich auf jeder OSD befinden.
    Code:
    datacenter WW {
        id -27        # do not change unnecessarily
        id -28 class ssd        # do not change unnecessarily
        # weight 5.094
        alg straw2
        hash 0    # rjenkins1
        item PX10-WW-SN03 weight 2.910
        item PX10-WW-N04 weight 0.728
        item PX10-WW-N03 weight 0.728
        item PX10-WW-N05 weight 0.728
    Das Verbessert auch die Latenz, da Ceph sehr sensible darauf regiert, kann das schon einiges an Einfluss für die IO haben.

    Dann ist auch entscheidend, ob die DB per sync schreibt oder ob doch ein Cache dazwischen ist. Da LXC über KRBD die Images bekommt, wird der Page Cache verwendet.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. norderstedt

    norderstedt Member

    Joined:
    Nov 28, 2016
    Messages:
    49
    Likes Received:
    2
    Hier mal die Verteilung der PGs:

    Code:
    ID  CLASS WEIGHT   REWEIGHT SIZE    USE     AVAIL   %USE  VAR  PGS TYPE NAME
     -1       15.28163        - 15.3TiB 2.78TiB 12.5TiB 18.17 1.00   - root default
    -26        5.09398        - 5.09TiB  948GiB 4.17TiB 18.17 1.00   -     datacenter BW
     -3        0.72800        -  745GiB  140GiB  605GiB 18.75 1.03   -         host PX10-BW-N03
      0   ssd  0.72800  1.00000  745GiB  140GiB  605GiB 18.75 1.03 151             osd.0
     -5        0.72800        -  745GiB  131GiB  615GiB 17.52 0.96   -         host PX10-BW-N04
      1   ssd  0.72800  1.00000  745GiB  131GiB  615GiB 17.52 0.96 141             osd.1
     -7        0.72800        -  745GiB  129GiB  616GiB 17.31 0.95   -         host PX10-BW-N05
      2   ssd  0.72800  1.00000  745GiB  129GiB  616GiB 17.31 0.95 140             osd.2
     -9        2.90999        - 2.91TiB  548GiB 2.37TiB 18.40 1.01   -         host PX10-BW-SN02
      3   ssd  0.72800  1.00000  745GiB  149GiB  596GiB 19.98 1.10 161             osd.3
      4   ssd  0.72800  1.00000  745GiB  137GiB  608GiB 18.35 1.01 148             osd.4
      5   ssd  0.72800  1.00000  745GiB  130GiB  615GiB 17.47 0.96 142             osd.5
      6   ssd  0.18199  1.00000  186GiB 25.0GiB  161GiB 13.42 0.74  27             osd.6
      7   ssd  0.18199  1.00000  186GiB 41.2GiB  145GiB 22.10 1.22  43             osd.7
      8   ssd  0.18199  1.00000  186GiB 37.6GiB  149GiB 20.21 1.11  40             osd.8
     21   ssd  0.18199  1.00000  186GiB 28.9GiB  157GiB 15.51 0.85  31             osd.21
    -25        5.09398        - 5.09TiB  947GiB 4.17TiB 18.17 1.00   -     datacenter HBS
    -11        0.72800        -  745GiB  135GiB  611GiB 18.06 0.99   -         host PX10-HBS-N03
      9   ssd  0.72800  1.00000  745GiB  135GiB  611GiB 18.06 0.99 146             osd.9
    -13        0.72800        -  745GiB  124GiB  621GiB 16.61 0.91   -         host PX10-HBS-N04
     10   ssd  0.72800  1.00000  745GiB  124GiB  621GiB 16.61 0.91 134             osd.10
    -15        0.72800        -  745GiB  137GiB  608GiB 18.39 1.01   -         host PX10-HBS-N05
     11   ssd  0.72800  1.00000  745GiB  137GiB  608GiB 18.39 1.01 149             osd.11
    -21        2.90999        - 2.91TiB  552GiB 2.37TiB 18.52 1.02   -         host PX10-HBS-SN01
     14   ssd  0.72800  1.00000  745GiB  132GiB  613GiB 17.76 0.98 144             osd.14
     15   ssd  0.72800  1.00000  745GiB  143GiB  602GiB 19.19 1.06 155             osd.15
     16   ssd  0.72800  1.00000  745GiB  134GiB  611GiB 17.94 0.99 145             osd.16
     17   ssd  0.18199  1.00000  186GiB 37.6GiB  149GiB 20.18 1.11  40             osd.17
     18   ssd  0.18199  1.00000  186GiB 43.8GiB  142GiB 23.53 1.29  46             osd.18
     19   ssd  0.18199  1.00000  186GiB 27.7GiB  159GiB 14.86 0.82  29             osd.19
     20   ssd  0.18199  1.00000  186GiB 34.0GiB  152GiB 18.27 1.01  36             osd.20
    -27        5.09367        - 5.09TiB  947GiB 4.17TiB 18.16 1.00   -     datacenter WW
    -17        0.72800        -  745GiB  136GiB  609GiB 18.23 1.00   -         host PX10-WW-N03
     12   ssd  0.72800  1.00000  745GiB  136GiB  609GiB 18.23 1.00 148             osd.12
    -19        0.72800        -  745GiB  137GiB  608GiB 18.35 1.01   -         host PX10-WW-N04
     13   ssd  0.72800  1.00000  745GiB  137GiB  608GiB 18.35 1.01 148             osd.13
    -31        0.72769        -  745GiB  139GiB  606GiB 18.66 1.03   -         host PX10-WW-N05
     29   ssd  0.72769  1.00000  745GiB  139GiB  606GiB 18.66 1.03 151             osd.29
    -23        2.90999        - 2.91TiB  536GiB 2.39TiB 17.98 0.99   -         host PX10-WW-SN03
     22   ssd  0.72800  1.00000  745GiB  142GiB  603GiB 19.06 1.05 153             osd.22
     23   ssd  0.72800  1.00000  745GiB  133GiB  612GiB 17.89 0.98 145             osd.23
     24   ssd  0.72800  1.00000  745GiB  132GiB  613GiB 17.77 0.98 144             osd.24
     25   ssd  0.18199  1.00000  186GiB 34.9GiB  151GiB 18.77 1.03  37             osd.25
     26   ssd  0.18199  1.00000  186GiB 28.8GiB  157GiB 15.49 0.85  30             osd.26
     27   ssd  0.18199  1.00000  186GiB 33.5GiB  153GiB 17.97 0.99  35             osd.27
     28   ssd  0.18199  1.00000  186GiB 30.8GiB  155GiB 16.55 0.91  33             osd.28
                          TOTAL 15.3TiB 2.78TiB 12.5TiB 18.17
    MIN/MAX VAR: 0.74/1.29  STDDEV: 1.94
    
    Heißt das im Gegenzug, da wir vorher die DB via KVM haben laufen lassen, dass alleine LXC durch den Page Cache hier Probleme machen kann? Alle LXC-Container haben keinen Swap konfiguriert, da die Hypervisor keinen Swap haben.

    Zu der Verteilung, wie gesagt, die sind auf allen OSDs:

    Code:
    osdmap e15221 pool 'PX-LIVE' (5) object 'rbd_data.1b92d96b8b4567.00000000000007c7' -> pg 5.5abfc44f (5.4f) -> up ([1,11,22], p1) acting ([1,11,22], p1)
    osdmap e15221 pool 'PX-LIVE' (5) object 'rbd_data.1b92d96b8b4567.0000000000000134' -> pg 5.4310e71f (5.31f) -> up ([5,10,29], p5) acting ([5,10,29], p5)
    osdmap e15221 pool 'PX-LIVE' (5) object 'rbd_data.1b92d96b8b4567.00000000000013ee' -> pg 5.7edc27f (5.27f) -> up ([14,5,12], p14) acting ([14,5,12], p14)
    ...
    
    All das erklärt mir aber trotz allem noch nicht, warum ich das Gefühl habe (und auch bei IOSTAT sehe), dass regelmäßig die Write Performance auf 0 geht, dann sofort wieder hochgeht. In der Zeit hängen alle SQL-Abfragen und brauchen dann 5-20 Sekunden. Danach läuft alles wieder ganz normal, bis wieder ein Einbruch kommt.

    Ich habe heute schon zu meinem Kollegen gesagt, es fühlt sich an, als ob da irgendwo ein Cache geleert wird, in dieser Zeit wird alles auf "Stopp" gesetzt und danach kann es weitergehen. Es gibt auch kein Muster, mal passiert das alle 10, mal alle 20 mal alle 3 Sekunden .. Ist wirklich kurios. Ich werde mal alle SQL-Server wieder in eine KVM legen und dann schauen, wie sich das dann verhält. Bevor wir mit LXC angefangen haben hatten wir die Probleme nicht.

    Ist es darüber hinaus schlimm, wenn LVM und LXC beide im gleichen Pool liegen? Wir haben zwar jeweils ein Storage mit und eins ohne KRBD angelegt, beide werden aber aus dem gleichen Ceph-Pool bedient.

    Und eine letzte Sache noch: Uns ist aufgefallen, dass egal welcher LXC-Container maximal 1 Gbit bekommt, egal wohin (gilt auch für KVM, alles auf unlimited gestellt), egal woher. Gibt es hier eine Default-Grenze?

    [​IMG]

    Ein letztes: Proxmox ist bei uns auf SD-Karten installiert. Kann es passieren, dass aufgrund von 100% Write Utilisation des Hostsystems auf die SD-Karte (also hoher IO-Wait für Writes auf die SD-Karte), andere Platten (also auch die SSDs im Ceph) beeinflusst werden, da das Hostsystem im Scheduler auch hier blockt?
     
    #8 norderstedt, Jan 11, 2019
    Last edited: Jan 11, 2019
  9. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,186
    Likes Received:
    192
    Der Page Cache wird an sich keine Probleme machen, es kann aber durchaus sein, dass die DB den nicht verwendet und mit sync auf die Platte schreibt. Anders als bei LXC spricht KVM (default setup) über librbd direkt mit dem Ceph Cluster, dabei ist von Haus aus ein 25MB grosser Cache aktiv. Sollte KRBD zum Einsatz kommen, dann KVM sein eigenes Caching verwenden. In beiden Fällen sieht die DB das nicht da ein sync auf die Platte in der VM geschrieben wird. Swap hat dabei keinen Einfluss.

    Das könnte zum einen durch das Schreibverhalten des DB servers her kommen, wenn dieser in periodischen Abständen seinen Cache auf die Platte schreibt. Wenn die OSDs sind über einen RAID Kontroller (hoffe nicht) angesteckt sind. Oder im Netzwerk ein Flaschenhals auftaucht (Bsp. Backbone). Vermutlich aber ersteres, da sich das Verhalten ja beim Umstieg von KVM auf LXC zeigte. Das Netzwerk Monitoring könnte dazu vielleicht mehr Aufschluss geben.

    Das ist kein Problem. Mit PVE 5.3 ist es nicht mehr nötig zwei Storages anzulegen. Die Container werden immer mit KRBD bedient (nicht anders Möglich). KRBD an/aus ist nur noch für KVM entscheidend.

    Damit wird der Download vom 'speedtest' Server zum Container gemessen, aber nicht die Disk IO. Ich hoffe die Netzwerke (VM/CT, cluster, storage) sind physisch getrennt.
    Code:
    net0: name=eth0,bridge=vmbr8,gw=172.xx.xx.xx,hwaddr=92:6E:02:04:B4:4F,ip=172.xx.xx.xx/24,type=veth
    net1: name=eth1,bridge=vmbr5,hwaddr=B2:0B:65:FB:16:25,ip=192.xx.xx.xx/24,type=veth
    Stammt der Traffic vielleicht von einem anderen Interface, mit einer Beschränkung (Bsp. physisch / Firewall)?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. Knuuut

    Knuuut Member

    Joined:
    Jun 7, 2018
    Messages:
    88
    Likes Received:
    8
    Host-OS auf SD?
    Swap auch?
    dmesg?
    Dem würde ich doch lieber eine kleine SSD spendieren....

    Was wir noch gar nicht hatten:

    Wie sind deine SSDs angebunden?
    HBA oder RAID-Controller?
    Sind die Kabel ok?
    SAS-Expander & Einschübe ok?
    ...
    tbc
     
  11. norderstedt

    norderstedt Member

    Joined:
    Nov 28, 2016
    Messages:
    49
    Likes Received:
    2
    Host-OS ist auf SD, wir verlegen das Logging jetzt auf eine SSD, SWAP geben wir ab sofort auch über eine SSD rein. Dmesg sieht gut aus. Alle SSDs sind ohne RAID-Controller angebunden, alles über SAS. Wir haben jetzt einmal das Galera-Cluster angepasst und sind schon einmal einige Probleme los. Wenn wir das Proxmox-Logging etc. verschieben dann sollte es besser gehen. Ich berichte.
     
  12. norderstedt

    norderstedt Member

    Joined:
    Nov 28, 2016
    Messages:
    49
    Likes Received:
    2
    Wir haben das Galera-Cluster angepasst (eve.write_speed) und nun scheinen die meisten Probleme behoben worden zu sein. Bezüglich der Problematik mit den Transferspeeds erstelle ich einen seperaten Thread. Danke an Alle!
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice