У нас есть сервер приложений с 2 твердотельными накопителями Fusion-IO, помещенными в одну группу томов, образующих один том. Внутри этого тома есть 128 файлов по 40 ГБ каждый, доступ к которым осуществляется через карту памяти.
При просмотре iostat мы обнаружили, что рабочая нагрузка неравномерно распределяется по обоим дискам. Разница составляет 25%.
В чем могут быть возможные причины этой проблемы? Как мне исследовать такую проблему?
>lsblk
NAME MAJ:MIN RM SIZE RO MOUNTPOINT
...
fioa 253:0 0 2.9T 0
└─instvg-instant (dm-17) 252:17 0 5.8T 0 /instant
fiob 253:16 0 2.9T 0
└─instvg-instant (dm-17) 252:17 0 5.8T 0 /instant
>iostat -xk -d fioa -d fiob
Linux 3.0.101-0.47.52-default (...) 08/10/2015 _x86_64_
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
fioa 0.00 0.00 1295.05 3116.02 65326.45 16359.80 37.04 0.29 0.07 0.01 3.82
fiob 0.00 0.00 1847.35 4090.05 88087.96 21608.44 36.95 0.42 0.02 0.01 5.98
Мне нужен вывод lvs -o +devices,segtype
чтобы подтвердить это, но я предполагаю, что вы только что распределили LV линейно по обоим PV. Это плохая идея с точки зрения балансировки нагрузки, потому что файловая система будет иметь тенденцию заполняться от начала до конца, и первая половина файловой системы находится на одном PV, а вторая половина - на другом PV. Итак, пока файловая система не будет заполнена наполовину, почти весь ввод-вывод будет выполняться на первом PV.
Чтобы исправить это, LV необходимо создать как striped
объем, а не linear
. Это можно сделать с помощью -i 2
перешел к lvcreate
. Преобразование LV в полосатый возможно, но только если у вас есть куча свободного места, которого, похоже, здесь нет. Что это будет делать, так это чередовать фрагменты LV на обоих PV, так что (например) первые 8 КБ данных будут на первом PV, следующие 8 КБ на втором PV, следующие 8 КиБ обратно на первом PV и скоро.
При этом ваш профиль ввода-вывода не ужасно из баланса. Вы никогда не получите идентичный ввод-вывод на обоих PV просто потому, что запросы, идущие к PV, не будут идеально сбалансированы.