LINUX.ORG.RU
ФорумAdmin

Дефрагментация в Linux и ocfs2

 , , ,


0

1

Приветствую, есть 2 ноды, на Oracle Linux 7 к которым подключен lun на raid10, по SAS. Размер примерно 8Тб. Диск форматирован в ocfs2 и используется одновременно с обеих нод. После форматирования диска через rsync было синхронизировано со старого хранилища, около 1.5 Тб. Полтора года все было нормально, но в последний месяц наблюдается жуткое падение производительности, в основном при попытке записи на диск. За это время объем данных вырос до 3Тб. При очистке места ситуация немного нормализуруется, но не долго. как только объем данных переваливает за ~40% от общего места, скорость записи опять падает. Файлы в основном картинки и lxc контейнеры. Есть предположение, что во всем виновата фрагментация. Изначально раздел создавался с размером кластера 4кб, но в инструкции Oracle (https://docs.oracle.com/cd/E37670_01/E37355/html/o... указано, что для такого объема размер кластера должен быть 64кб, не знаю -

  • может помочь переформатирование?
  • Существуют ли какие-либо утилиты для дефрагментации ocfs2?
  • Может дело быть не в фрагментации?

    Текущая конфигурация такая: IBM Storwize V3700, 4x4TB HHD in RAID10. Linux Oracle 7, Kernel: 3.8.13-118.4.2.el7uek.x86_64 OCFS2 1.8.

    # dd if=/dev/zero of=/storage/tmp.dd bs=100M count=10
    10+0 записей получено
    10+0 записей отправлено
     скопировано 1048576000 байт (1,0 GB), 70,4514 c, 14,9 MB/c
    # df -h
    /dev/sdb1             7,3T         2,8T  4,6T           39% /storage
    # df -hi
    /dev/sdb1             1,9G          709M      1,2G            39% /storage
    
    o2info --freefrag 4096 /dev/sdb1
    Blocksize: 4096 bytes
    Clustersize: 4096 bytes
    Total clusters: 1951924215
    Free clusters: 1196287822 (61.3%)
    
    Min. free extent: 4 KB 
    Max. free extent: 129020 KB
    Avg. free extent: 1516 KB
    
    Chunksize: 4194304 bytes (1024 clusters)
    Total chunks: 1906176
    Free chunks: 834956 (43.8%)
    
    HISTOGRAM OF FREE EXTENT SIZES:
    Extent Size Range :  Free extents  Free Clusters  Percent
        4K...    8K-  :        176176        176176    0.01%
        8K...   16K-  :        487972       1127391    0.09%
       16K...   32K-  :        822697       4637219    0.39%
       32K...   64K-  :       1133735      12600352    1.05%
       64K...  128K-  :        810457      15934501    1.33%
      128K...  256K-  :        510417      22477666    1.88%
      256K...  512K-  :        415926      34976315    2.92%
      512K... 1024K-  :        294126      52133455    4.36%
        1M...    2M-  :        110231      41036881    3.43%
        2M...    4M-  :         40731      29937529    2.50%
        4M...    8M-  :         26128      36039039    3.01%
        8M...   16M-  :         27724      94755846    7.92%
       16M...   32M-  :         67461     360179568   30.11%
       32M...   64M-  :         13724     162048485   13.55%
       64M...  128M-  :         35195    1020608299   85.31%
    
    #find "/storage/postgresql/report/" -type f -exec filefrag {} \; | sort -n -t : -k 2
    
    /storage/postgresql/report/base/405332397/405333410: 7514 extents found
    /storage/postgresql/report/base/405332397/405332593.1: 7708 extents found
    /storage/postgresql/report/base/405332397/405332593.6: 8045 extents found
    /storage/postgresql/report/base/405332397/405332662: 8340 extents found
    /storage/postgresql/report/base/405332397/405333748.3: 9067 extents found
    /storage/postgresql/report/base/405332397/405333180: 9698 extents found
    /storage/postgresql/report/base/405332397/405333541: 10354 extents found
    /storage/postgresql/report/base/405332397/405333748.1: 10829 extents found
    /storage/postgresql/report/base/405332397/405333748: 11158 extents found
    /storage/postgresql/report/base/405332397/405333748.2: 11168 extents found
    /storage/postgresql/report/base/215347687/406801962: 11376 extents found
    /storage/postgresql/report/base/405332397/405333177: 12732 extents found
    # modinfo ocfs2
    filename:       /lib/modules/3.8.13-118.4.2.el7uek.x86_64/kernel/fs/ocfs2/ocfs2.ko
    license:        GPL
    author:         Oracle
    version:        1.8.0
    description:    OCFS2 1.8.0
    srcversion:     C2F2928C6340706B57561A8
    depends:        jbd2,ocfs2_stackglue,ocfs2_nodemanager
    intree:         Y
    vermagic:       3.8.13-118.4.2.el7uek.x86_64 SMP mod_unload modversions 
    signer:         Oracle CA Server
    sig_key:        BC:51:CE:95:28:97:32:9F:78:F8:42:9C:3B:A0:C5:57:2B:7D:FE:AD
    sig_hashalgo:   sha512
    
    # cat /proc/mounts
    
    ocfs2_dlmfs /dlm ocfs2_dlmfs rw,relatime 0 0
    /dev/sdb1 /storage ocfs2 rw,relatime,_netdev,heartbeat=local,nointr,data=ordered,errors=remount-ro,atime_quantum=60,coherency=buffered,user_xattr,acl 0 0

    Вот вывод ядра после разворачивания 30Гб базы postgresql из sql дампа.

    # less /var/log/messages
    
    Mar 28 04:46:39 node-1 kernel: INFO: task postgres:10708 blocked for more than 120 seconds.
    Mar 28 04:46:39 node-1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    Mar 28 04:46:39 node-1 kernel: postgres        D ffff880667c73100     0 10708  10696 0x00000180
    Mar 28 04:46:39 node-1 kernel: ffff880577511820 0000000000000082 ffff880584244100 ffff880577511fd8
    Mar 28 04:46:39 node-1 kernel: ffff880577511fd8 ffff880577511fd8 ffff880584244100 7fffffffffffffff
    Mar 28 04:46:39 node-1 kernel: ffff8805775119f8 ffff880577511a00 ffff880584244100 0000000000000000
    Mar 28 04:46:39 node-1 kernel: Call Trace:
    Mar 28 04:46:39 node-1 kernel: [<ffffffff8157d539>] schedule+0x29/0x70
    Mar 28 04:46:39 node-1 kernel: [<ffffffff8157bb79>] schedule_timeout+0x1d9/0x2e0
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa0752849>] ? ocfs2_metadata_cache_unlock+0x19/0x20 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa008f020>] ? o2dlm_lock_ast_wrapper+0x20/0x20 [ocfs2_stack_o2cb]
    Mar 28 04:46:39 node-1 kernel: [<ffffffff8157e99e>] ? _raw_spin_lock+0xe/0x20
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa07047a2>] ? ocfs2_inode_cache_unlock+0x12/0x20 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa0752849>] ? ocfs2_metadata_cache_unlock+0x19/0x20 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffff8157da0a>] wait_for_common+0x11a/0x170
    Mar 28 04:46:39 node-1 kernel: [<ffffffff81093130>] ? wake_up_state+0x20/0x20
    Mar 28 04:46:39 node-1 kernel: [<ffffffff8157da7d>] wait_for_completion+0x1d/0x20
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa06f86f0>] __ocfs2_cluster_lock.isra.31+0x1a0/0x830 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa07047a2>] ? ocfs2_inode_cache_unlock+0x12/0x20 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa0752849>] ? ocfs2_metadata_cache_unlock+0x19/0x20 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffff8157e99e>] ? _raw_spin_lock+0xe/0x20
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa06f9d31>] ocfs2_inode_lock_full_nested+0x1f1/0x4d0 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa0712f6f>] ocfs2_lookup_lock_orphan_dir.constprop.25+0x5f/0x1b0 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa071547d>] ocfs2_prepare_orphan_dir+0x3d/0x2a0 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffffa0717889>] ocfs2_rename+0x10d9/0x1ae0 [ocfs2]
    Mar 28 04:46:39 node-1 kernel: [<ffffffff81195e88>] vfs_rename+0x358/0x4c0
    Mar 28 04:46:39 node-1 kernel: [<ffffffff81198a81>] sys_renameat+0x391/0x430
    Mar 28 04:46:39 node-1 kernel: [<ffffffff81020a93>] ? syscall_trace_enter+0x223/0x240
    Mar 28 04:46:39 node-1 kernel: [<ffffffff81198b3b>] sys_rename+0x1b/0x20
    Mar 28 04:46:39 node-1 kernel: [<ffffffff815871c7>] tracesys+0xdd/0xe2
    
    Mar 30 05:32:39 node-1 kernel: INFO: task postgres:10708 blocked for more than 120 seconds.
    Mar 30 05:32:39 node-1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    Mar 30 05:32:39 node-1 kernel: postgres        D ffff880667cf3100     0 10708  10696 0x00000180
    Mar 30 05:32:39 node-1 kernel: ffff880577511820 0000000000000082 ffff880584244100 ffff880577511fd8
    Mar 30 05:32:39 node-1 kernel: ffff880577511fd8 ffff880577511fd8 ffff880584244100 7fffffffffffffff
    Mar 30 05:32:39 node-1 kernel: ffff8805775119f8 ffff880577511a00 ffff880584244100 0000000000000000
    Mar 30 05:32:39 node-1 kernel: Call Trace:
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157d539>] schedule+0x29/0x70
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157bb79>] schedule_timeout+0x1d9/0x2e0
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa0752849>] ? ocfs2_metadata_cache_unlock+0x19/0x20 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa008f020>] ? o2dlm_lock_ast_wrapper+0x20/0x20 [ocfs2_stack_o2cb]
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157e99e>] ? _raw_spin_lock+0xe/0x20
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa07047a2>] ? ocfs2_inode_cache_unlock+0x12/0x20 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa0752849>] ? ocfs2_metadata_cache_unlock+0x19/0x20 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157da0a>] wait_for_common+0x11a/0x170
    Mar 30 05:32:39 node-1 kernel: [<ffffffff81093130>] ? wake_up_state+0x20/0x20
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157da7d>] wait_for_completion+0x1d/0x20
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa06f86f0>] __ocfs2_cluster_lock.isra.31+0x1a0/0x830 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa07047a2>] ? ocfs2_inode_cache_unlock+0x12/0x20 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa0752849>] ? ocfs2_metadata_cache_unlock+0x19/0x20 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157e99e>] ? _raw_spin_lock+0xe/0x20
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa06f9d31>] ocfs2_inode_lock_full_nested+0x1f1/0x4d0 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa0712f6f>] ocfs2_lookup_lock_orphan_dir.constprop.25+0x5f/0x1b0 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa071547d>] ocfs2_prepare_orphan_dir+0x3d/0x2a0 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa0717889>] ocfs2_rename+0x10d9/0x1ae0 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffff81195e88>] vfs_rename+0x358/0x4c0
    Mar 30 05:32:39 node-1 kernel: [<ffffffff81198a81>] sys_renameat+0x391/0x430
    Mar 30 05:32:39 node-1 kernel: [<ffffffff81020a93>] ? syscall_trace_enter+0x223/0x240
    Mar 30 05:32:39 node-1 kernel: [<ffffffff81198b3b>] sys_rename+0x1b/0x20
    Mar 30 05:32:39 node-1 kernel: [<ffffffff815871c7>] tracesys+0xdd/0xe2
    Mar 30 05:32:39 node-1 kernel: INFO: task java:7710 blocked for more than 120 seconds.
    Mar 30 05:32:39 node-1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    Mar 30 05:32:39 node-1 kernel: java            D ffff880667c73100     0  7729      1 0x00000080
    Mar 30 05:32:39 node-1 kernel: ffff880463aefc40 0000000000000082 ffff88042a7e2380 ffff880463aeffd8
    Mar 30 05:32:39 node-1 kernel: ffff880463aeffd8 ffff880463aeffd8 ffff88042a7e2380 ffff880c5328d5e8
    Mar 30 05:32:39 node-1 kernel: ffff880c5328d5ec ffff88042a7e2380 00000000ffffffff ffff880c5328d5f0
    Mar 30 05:32:39 node-1 kernel: Call Trace:
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157dbe9>] schedule_preempt_disabled+0x29/0x70
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157c617>] __mutex_lock_slowpath+0x117/0x1d0
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8157bf8f>] mutex_lock+0x1f/0x30
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa0712f59>] ocfs2_lookup_lock_orphan_dir.constprop.25+0x49/0x1b0 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa071547d>] ocfs2_prepare_orphan_dir+0x3d/0x2a0 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffffa071631c>] ocfs2_unlink+0x73c/0xbd0 [ocfs2]
    Mar 30 05:32:39 node-1 kernel: [<ffffffff811955c0>] vfs_rmdir+0xc0/0x120
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8119579d>] do_rmdir+0x17d/0x1d0
    Mar 30 05:32:39 node-1 kernel: [<ffffffff8107dd8c>] ? task_work_run+0xac/0xe0
    Mar 30 05:32:39 node-1 kernel: [<ffffffff81198316>] sys_rmdir+0x16/0x20
    Mar 30 05:32:39 node-1 kernel: [<ffffffff81586fb9>] system_call_fastpath+0x16/0x1b
    
    


Вообще, использовать кластерную ФС для хранения СУБД - так себе идея, по-моему.

А в остальном - смотреть i/o wait какой во время пиков нагрузки и тормозов, смотреть iostat сколько iops-ов летит к СХД и так далее. Дальше уже будет понятно - СХД задыхается или твои ноды. Плюс статистика по этому луну с СХД будет не лишней.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

БД на SSD дисках на самих серверах. На сторадж каждую ночь разворачивается дамп из бекапа, и некоторое ПО потом его обрабатывает. Возможно это и создает сильную фрагментацию. Но вот винова-то ли в этом ocfs2 или такое же может произойти на другой ФС? За iostat - спасиб, но пока нагрузки нет, попробую потом проверить. Я проверял в пиках atop'ом диск был busy на 100% Load Average - 40 (из 32 потоков),фишка еще в том что при низкой скорости ocfs2 ставит блокировки приложений пока не обработает очередь. Cуществует ли какой либо онлайн дефрагментатор, который работает с файлами, а не с ФС. Просто для ocfs2 я такой не нашел.

schmel
() автор топика
Ответ на: комментарий от schmel

у вас, наверное видна с "раздельными потоками",

тогда пробуем убирать «хадэ» с звуковых источников, а, ежели табличные данные, то «вширь» не более 81 столбца переделываем, и всё это в моменты «пиков» нагрузок :pwd коммандкой прописываем, смотрим. Как-то так это делается..

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.