Влияет ли LVM на производительность?

Мне нужно перенести несколько серверов на Linux, и один важный аспект, который мне нужно оценить, заключается в том, что моя новая хост-система должна иметь эластичную емкость хранилища. Естественно, проводя некоторые фундаментальные исследования, я наткнулся на LVM.

Есть ли какие-либо потери производительности при использовании lvm? Если да, то как я могу это измерить?

Сейчас я думаю о том, чтобы иметь Linux в качестве хост-ОС с LVM и виртуализированными Linux-блоками, работающими поверх нее (стоит ли также добавлять LVM в гостевую ОС?).

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

Но это не так. Ядро уже должно иметь отображение (или несколько уровней отображения), которое связывает высокоуровневые операции, такие как «записать это в файл», с драйверами устройств, которые, в свою очередь, подключаются к реальным блокам на диске.

Когда LVM используется, этот поиск изменяется, но это все. (Так как это должно произойти в любом случае, сделать это немного иначе - это незначительный удар по производительности.) Когда дело доходит до записи файла, биты выбирают такой же прямой путь к физическому носителю, как и в противном случае.

Есть случаи, когда LVM может вызвать проблемы с производительностью. Вы хотите убедиться, что блоки LVM правильно выровнены с базовой системой, что должно происходить автоматически с современными дистрибутивами. И убедитесь , что вы не используете старые ядра предметных к ошибкам , как этот . Да, и использование снимков LVM снижает производительность (и все более и более с каждым активным снимком). Но в основном воздействие должно быть очень маленьким.

Что касается последнего: как вы можете проверить? Стандартный инструмент для тестирования производительности дисков - Бонни ++ . Создайте раздел с LVM, протестируйте его, сотрите его и (в том же месте, чтобы другие факторы были идентичными) создайте простую файловую систему и снова выполните тестирование. Они должны быть близки к одинаковым.

LVM, как и все остальное, является смешанным благословением.

Что касается производительности, LVM немного помешает вам, потому что это еще один уровень абстракции, который необходимо проработать, прежде чем биты попадут (или могут быть прочитаны) на диск. В большинстве ситуаций это снижение производительности будет практически неизмеримо.

Преимущества LVM включают в себя тот факт, что вы можете добавить больше памяти для существующих файловых систем без необходимости перемещения данных. Большинству людей нравится это за это преимущество.

Одним из недостатков LVM, используемых таким образом, является то, что если ваше дополнительное хранилище охватывает диски (т.е. включает более одного диска), вы повышаете вероятность того, что сбой диска будет стоить вам данных. Если ваша файловая система охватывает два диска, и один из них выходит из строя, вы, вероятно, потерялись. Для большинства людей это приемлемый риск , связанный с пространственно-против-затрат причинам (например , если это действительно важно будет бюджет , чтобы сделать это правильно) - и потому, что, как они говорят, резервные копии являются хорошо, верно?

Для меня единственная причина не использовать LVM состоит в том, что аварийное восстановление не (или, по крайней мере, не было) четко определено. Диск с томами LVM, на котором установлена ​​зашифрованная ОС, не может быть просто подключен к другому компьютеру и восстановленным с него данным; во многих инструкциях по восстановлению томов LVM, по-видимому, содержались такие шаги, как возврат в прошлое и запуск vgcfgbackup, а затем копирование полученного файла / etc / lvmconf в систему, в которой находится ваш скрытый том . Надеюсь, что все изменилось за три или четыре года, с тех пор как мне в последний раз приходилось смотреть на это, но лично я никогда не использую LVM по этой причине.

Это сказал.

В вашем случае я бы предположил, что виртуальные машины будут относительно небольшими по сравнению с хост-системой. Для меня это означает, что вы с большей вероятностью захотите расширить хранилище в ВМ позже; это лучше всего сделать, добавив другой виртуальный диск к виртуальной машине, а затем увеличив уязвимые файловые системы виртуальной машины. У вас нет уязвимости spanning-множественных дисков, потому что виртуальные диски, скорее всего, будут находиться на одном физическом устройстве в хост-системе.

Если виртуальные машины будут иметь какое-то значение для вас, вы каким-то образом будете использовать RAID-массив для хост-системы, что снизит гибкость для увеличения объема хранилища в дальнейшем. Таким образом, гибкость LVM, вероятно, не потребуется.

Поэтому я бы предположил, что вы не будете использовать LVM в хост-системе, а установите виртуальные машины для использования LVM.

В общем: если вы добавите новый уровень сложности («еще что-то делать»), ничего не будет быстрее. Примечание: вы только добавляете работу, а не «меняете» их способ выполнения работы.

Как вы можете измерить что-то? Итак, вы создаете один раздел с LVM и один без, затем используете обычный тест и просто запускаете его. Как люди в

http://www.umiacs.umd.edu/~toaster/lvm-testing/

Как кажется, лишь незначительное влияние на скорость. Похоже, это согласуется с результатами кого-то еще, кто проводил тестирование:

«ext4 быстрее с LVM, чем без, и другие тесты файловой системы» Поток списка рассылки ядра Linux

Но просто сравните его самостоятельно и посмотрите, будут ли ваши аппаратные средства и ОС, которые вы хотите использовать, вести себя одинаково, и если вы можете игнорировать (возможно, немного) влияние дополнительного уровня сложности, который дает вам гибкое хранилище.

Если вы добавите LVM в гостевую ОС: это зависит от того, нужна ли вам гостевая ОС для эластичного хранилища, не так ли? Ваши потребности диктуют, что вы должны развернуть.

Стоит ли добавить LVM на гостевую ОС?

Вы не должны этого делать, поскольку достаточно иметь файловую систему ext3 или ext 4 внутри логического тома хоста. Нет необходимости добавлять еще одну группу томов, физический том и логический том внутри.

Не будет большого снижения производительности только от lvm, но если вы готовы принять его, используйте вместо этого zfs. Вы получаете управление громкостью и возможность восстановления, а также множество других замечательных функций.

Ни одно упоминание lvm2 не может заставить умножаться скорость чтения и записи (аналогично raid0). Лично я использую 3 одинаковых диска и над ними lvm2 в режиме чередования, операции чтения и записи занимают 1/3 времени, это большое влияние, файловая система работает на три скорости быстрее. Я знаю: сбой любого диска и все данные на них не будут доступны; но это не означает потерю, поскольку резервные копии ДОЛЖНЫ, ничего подобного Raid, LVM2, ZFS не будут иметь резервных копий; поэтому я никогда не использую зеркалирование, raid5 и тому подобное, я всегда использую чередование (чтобы добиться максимальной производительности) и синхронизировал резервные копии. ZFS отлично подходит для сжатия «на лету», а параметр копирования больше единицы подобен зеркальному отображению, но у ZFS есть одна вещь, которой больше нет у других: автоматическое восстановление на лету сгнивших бит (биты, которые самопроизвольно изменяются во время диск выключен),

Чтобы возобновить: я использую ZFS только для своих резервных копий на внешних дисках, несколько (два или три) ssd с lvm2, чередующиеся для ОС (aftwr обновляет я повторяю клон ОС), я склонен использовать неизменяемую ОС; и я использую несколько (шесть) дисков spinnin с разделом lvm2 для данных, как виртуальные машины, опять же после любых изменений, которые я делаю, создаю резервные копии; поэтому после любого отказа диска мне нужно только заменить его и восстановить последнюю резервную копию; сейчас у меня скорость записи около 1,8 ГБ / с, поэтому восстановление одной виртуальной машины из резервной копии занимает менее 30 секунд (32 ГБ на диск виртуальной машины).

Итак, мой ответ: не используйте только одну вещь, будьте умны и используйте лучшее из каждой части, lvm2 раздет быстрее, чем mdraid уровня 0, больше при использовании шести вращающихся дисков; одно предупреждение с разбором ssd, два и три - хорошо, четыре ssd могут снизить производительность (мои тесты показали более низкую скорость записи, когда я использовал четыре идентичных ssd в раздетом режиме, независимо от того, lvm, mdraid0 и т. д.), кажется, что SSD TRIM и подобные усиление записи может быть основной причиной добавления большего количества ssd в очищенный том, что снижает скорость записи.

Работая с ssd и любым raid0 (очищенные тома), выровняйте вещи идеально, правильно назначьте размеры кластеров в файловой системе, размер и т. Д., Чтобы никто не вызывал ухудшение; в качестве примера: сектор диска равен 2048, поэтому 2 КБ при любом чтении / записи минимально, никогда не используйте файловую систему, которая использует 512-байтовый кластер, более того, лучше использовать размер кластера 2 КБ или 4 КБ; Теперь представьте, что вы используете 3xHDD, каждый из 2K секторов, поэтому в любом кластере файловой системы optimun для чтения / записи будет 3x2K = 6K, но это невозможно во многих файловых системах, а затем подумайте, что если использовать размер кластера 64K, 64K / 6K = 32 / 3, что вызывает несбалансированность, поэтому не оптимален и т. Д. Сделать математику, чтобы получить оптимальный размер кластера.

Мои лучшие результаты: Размер кластера = размер полосы * количество дисков на полосе; таким образом, каждое чтение / запись имеет точный размер, который заставляет работать все диски, так что повышение скорости очень велико. Пример размера кластера 192 КБ для 3 дисков с размером полосы 64 КБ; Другой пример: размер кластера 192 КБ для 6 дисков с размером полосы 32 КБ.

И всегда не забывайте тестировать один диск в 4K, 8K, 16K, 32K, 64K блоке; Многие диски дают действительно плохие скорости с меньшими числами, такими как 4K, но дают более чем в десять раз более быстрое время при 64K, 128K или выше.

Да, использование кластеров большого размера может привести к потере места на кластере las каждого файла (если вы используете миллионы файлов по 1 байту в каждом), лучше использовать компактную / pack систему «на лету» поверх файловой системы, Например, диск размером 4 ТБ с размером кластера 4 КБ может иметь только файлы размером менее 4 ТБ / 4 КБ = 1073741824 по 1 Байт каждый, то есть всего 1 ГБ, если все файлы имеют размер 1 Байт (размер кластера 4 КБ), наихудшее соотношение размера кластера больше, но если файлы огромные, например, виртуальные машины (около 32 ГБ в качестве примера или всего несколько мегабайт), потерянные только на последнем кластере; такие большие файлы, большой размер кластера намного лучше для производительности, но будьте осторожны, как виртуальная машина использует это.

Никто не скажет вам этот секрет: в гостевой системе не используйте размер кластера 4K, используйте тот же размер кластера, что и размер кластера, где находится виртуальный диск, или кратный ему.

Да, я безумно стремлюсь получить максимальную скорость на гостевых дисках, поскольку, как я сказал, с 6 вращающимися дисками я получаю скорость около 1,7 ГБ / с, скорость шины SATA III является узким местом, а не самими дисками. Я использую высокопроизводительные (не дешевые) диски, кэш 128 МБ со скоростью записи 283 МБ / с каждый.

Для вас и для всех людей: гораздо лучше узнать, как размер кластера, размер полосы и размер блока должны быть связаны до проведения любого теста скорости, иначе тестирование LVM2 или любого другого RAID (также ZFS) может дать ложные выводы.

Просто пример для этого: я тестирую время загрузки Linux с 2x60 МБ / с 2,5-дюймовыми дисками Sata 5400 об / мин на материнской плате портов Sata II, а затем тестирую с 2xSSD Sata III (они могут записывать более 250 МБ / с каждый при подключении к Sata III порты), время загрузки занимает всего две секунды меньше, всего две секунды при пятиминутной загрузке, почему? Поскольку большинство дисков начальной загрузки не используются, он выполняет операции с оперативной памятью и процессором, но не с операциями ввода-вывода.

Всегда проверяйте в реальном времени, что вы будете делать, а не только грубые скорости (другими словами, максимальная скорость).

Максимальная скорость - это хорошо знать, что бит не может быть представлен, возможно, вы не используете диски на максимальной скорости 100% времени, ОС и приложения должны выполнять операции на оперативной памяти и процессоре без ввода-вывода, поэтому в это время скорость диска не имеет значение вообще.

Все говорят, что SSD значительно повышает скорость загрузки Windows, на моих тестах это также ЛОЖЬ, только я докажу 28 секунд при времени загрузки около восьми минут.

Так что, если вы мне нравитесь: копирование Linux в оперативную память при загрузке, SSD не будет лучше, чем вращающиеся жесткие диски, я также протестировал флешку USB 3.1 Gen2 (чтение 139 МБ / с), время загрузки зависит только от нескольких секунд пять минут загрузки, почему? просто, чтение выполняется при копировании в оперативную память, если диск / ssd / usb-stick больше не используется на остальной части болта, данные находятся на оперативной памяти, как оперативная память.

Теперь я продаю все свои SSD, которые у меня есть, они не улучшают копирование на оперативной памяти Linux при загрузке, но их тестирование говорит, что они в 5 раз быстрее ... видите, тесты дают ложные выводы ... да, тестируйте и тестируйте реально дневная работа.

Надеюсь, это может прояснить ситуацию с мужчинами ... LVM с плохими размерами кластеров и полосок влияет гораздо больше, чем накладные расходы слоя.