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

<p>я должен перенести несколько серверов в linux, и один важный аспект, который мне нужно оценить, заключается в том, что моя новая хост-система должна иметь эластичную емкость хранилища. естественно, проводя некоторые фундаментальные исследования, я наткнулся на lvm.</p><p>есть ли какие-либо потери производительности при использовании lvm? если да, то как я могу это измерить?</p><p>сейчас я думаю о том, чтобы иметь linux в качестве хост-ос с lvm и виртуализированными linux-блоками, работающими поверх нее (стоит ли добавлять lvm и на гостевую ос?).</p>

<p>lvm спроектирован таким образом, чтобы не мешать ему в действительности. с точки зрения пользовательского пространства это выглядит как еще один слой "виртуальных вещей" поверх диска, и кажется естественным представить, что все операции ввода-вывода теперь должны проходить через него, прежде чем он доберется до или от реального аппаратное обеспечение.</p><p>но это не так. ядро <em> уже</em> должно иметь отображение (или несколько уровней отображения фактически), которое связывает высокоуровневые операции, такие как "записать это в файл", с драйверами устройств, которые, в свою очередь, подключаются к реальным блокам на диск.</p><p>когда lvm используется, этот поиск изменяется, но это все. (так как это должно произойти в любом случае, делать это немного иначе - это незначительное снижение производительности.) <strong> когда дело доходит до фактической записи файла, биты принимают прямой путь к физическому носителю, так как они бы иначе. </strong></p><p>есть случаи, когда lvm может вызвать проблемы с производительностью. вы хотите убедиться, что блоки lvm правильно выровнены с базовой системой, что должно происходить автоматически с современными дистрибутивами. и убедитесь, что вы не используете старые ядра с ошибками вроде <a href="https://bugzilla.redhat.com/show\_bug.cgi?id=232843">эта</a> . да, и использование снимков lvm снижает производительность (и все более и более с каждым активным снимком). но в основном воздействие должно быть очень маленьким.</p><p>что касается последнего: как вы можете проверить? стандартный инструмент для тестирования производительности дисков <a href="http://www.coker.com.au/bonnie++/">bonnie ++</a> . создайте раздел с lvm, протестируйте его, сотрите его и (в том же месте, чтобы другие факторы были идентичными) создайте простую файловую систему и снова выполните тестирование. они должны быть близки к одинаковым.</p>

<p>lvm, как и все остальное, является смешанным благословением.</p><p>что касается производительности, lvm немного помешает вам, потому что это еще один уровень абстракции, который необходимо проработать, прежде чем биты попадут (или могут быть прочитаны) на диск. в большинстве ситуаций это снижение производительности будет практически неизмеримо.</p><p>преимущества lvm включают в себя тот факт, что вы можете добавить больше памяти для существующих файловых систем без необходимости перемещения данных. большинству людей нравится это за это преимущество.</p><p>одним из недостатков lvm, используемых таким образом, является то, что если ваше дополнительное хранилище охватывает диски (т.е. включает в себя более одного диска), вы повышаете вероятность того, что сбой диска будет стоить вам данных. если ваша файловая система охватывает два диска, и один из них выходит из строя, вы, вероятно, потерялись. для большинства людей это приемлемый риск из-за нехватки места и стоимости (то есть, если это действительно важно, будет бюджет, чтобы сделать это правильно) - и потому что, как говорится, резервные копии <em>есть</em> хорошо, верно?</p><p>для меня единственная причина не использовать lvm состоит в том, что аварийное восстановление не (или, по крайней мере, не было) четко определено. диск с томами lvm, на котором установлена зашифрованная ос, не может быть просто подключен к другому компьютеру и восстановленным с него данным; многие инструкции по восстановлению томов lvm, по-видимому, включают в себя такие шаги, как <em>вернитесь во времени и запустите vgcfgbackup, затем скопируйте полученный файл/etc/lvmconf в систему, в которой находится ваш скрытый том</em>. надеюсь, все изменилось за три или четыре года, с тех пор как мне в последний раз приходилось смотреть на это, но лично я никогда не использую lvm по этой причине.</p><p>это сказал.</p><p>в вашем случае я бы предположил, что виртуальные машины будут относительно небольшими по сравнению с хост-системой. для меня это означает, что вы, скорее всего, захотите расширить хранилище в vm позже; лучше всего это сделать, добавив другой виртуальный диск в vm, а затем рост затронутых vm файловых систем. у вас нет уязвимости spanning-множественных дисков, поскольку вполне вероятно, что виртуальные диски будут находиться на одном физическом устройстве в хост-системе.</p><p>если виртуальные машины будут иметь какое-то значение для вас, вы каким-то образом будете использовать raid-систему для хост-системы, что снизит гибкость для увеличения объема хранилища. таким образом, гибкость lvm, вероятно, не потребуется.</p><p>поэтому я бы предположил, что вы не будете использовать lvm в хост-системе, а установите виртуальные машины для использования lvm.</p>

<p>в общем: если вы добавите новый уровень сложности ("еще что-то делать"), ничего не будет быстрее. примечание: вы только добавляете работу, а не "меняете" их способ выполнения работы.</p><p>как вы можете измерить что-то? итак, вы создаете один раздел с lvm и один без, затем используете обычный тест и просто запускаете его. как люди в</p><p> <a href="http://www.umiacs.umd.edu/~toaster/lvm-testing/">http://www.umiacs.umd.edu/~toaster/lvm-testing/</a> </p><p>как кажется, лишь незначительное влияние на скорость. похоже, это согласуется с результатами кого-то еще, кто проводил тестирование:</p><p> <a href="https://lkml.org/lkml/2010/5/7/223">"ext4 быстрее с lvm, чем без, и другие тесты файловой системы" поток списка рассылки ядра linux</a> </p><p>но просто сравните его самостоятельно и посмотрите, будут ли ваши аппаратные средства и ос, которые вы хотите использовать, вести себя одинаково, и если вы можете игнорировать (возможно, немного) влияние дополнительного уровня сложности, который дает вам гибкое хранилище.</p><p>если вы добавите lvm в гостевую ос: это зависит от того, нужна ли вам гостевая ос для эластичного хранилища, не так ли? ваши потребности диктуют, что вы должны развернуть.</p>

<p>lvm медленнее, чем обычный раздел, особенно для маленьких файлов. хорошее исследование: <a href="https://www.researchgate.net/publication/284897601\_lvm\_in\_the\_linux\_environment\_performance\_examination">https://www.researchgate.net/publication/284897601\_lvm\_in\_the\_linux\_environment\_performance\_examination</a> </p>

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

<p>ни одно упоминание lvm2 не может заставить умножаться скорость чтения и записи (аналогично raid0). лично я использую 3 одинаковых диска и над ними lvm2 в режиме чередования, операции чтения и записи занимают 1/3 времени, это большое влияние, файловая система работает на три скорости быстрее. я знаю: сбой любого диска и все данные на них не будут доступны; но это не означает потерю, поскольку резервные копии должны, ничего подобного raid, lvm2, zfs не будут иметь резервных копий; поэтому я никогда не использую зеркалирование, raid5 и тому подобное, я всегда использую чередование (чтобы добиться максимальной производительности) и синхронизировал резервные копии. zfs отлично подходит для сжатия "на лету", а параметр копирования больше единицы подобен зеркальному отображению, но у zfs есть одна вещь, которой больше нет у других: автоматическое восстановление на лету, гниение битов (биты, которые самопроизвольно меняются, пока диск отключен), но zfs i оказывает очень большое влияние (вычисление контрольных сумм, проверка их) и проблема мэра (добавление большего количества физических дисков).</p><p>чтобы возобновить: я использую zfs только для своих резервных копий на внешних дисках, несколько (два или три) ssd с lvm2, чередующиеся для ос (aftwr обновляет я повторяю клон ос), я склонен использовать неизменяемую ос; и я использую несколько (шесть) дисков spinnin с разделом lvm2 для данных, как виртуальные машины, опять же после любых изменений, которые я делаю, создаю резервные копии; поэтому после любого отказа диска мне нужно только заменить его и восстановить последнюю резервную копию; сейчас у меня скорость записи около 1,8 гб/с, поэтому восстановление одной виртуальной машины из резервной копии занимает менее 30 секунд (32 гб на диск виртуальной машины).</p><p>итак, мой ответ: не используйте только одну вещь, будьте умны и используйте лучшее из каждой части, lvm2 раздет быстрее, чем mdraid уровня 0, больше при использовании шести вращающихся дисков; одно предупреждение с разбором ssd, два и три - хорошо, четыре ssd могут снизить производительность (мои тесты показали более низкую скорость записи, когда я использовал четыре идентичных ssd в раздетом режиме, независимо от того, lvm, mdraid0 и т. д.), кажется, что ssd trim и подобные усиление записи может быть основной причиной добавления большего количества ssd в очищенный том, что снижает скорость записи.</p><p>работая с ssd и любым raid0 (очищенные тома), выровняйте вещи идеально, правильно назначьте размеры кластеров в файловой системе, размер и т.д., чтобы никто не вызывал ухудшение; в качестве примера: сектор диска равен 2048, поэтому 2 кб при любом чтении/записи минимально, никогда не используйте файловую систему, которая использует 512-байтовый кластер, более того, лучше использовать размер кластера 2к или 4к; теперь представьте, что вы используете 3xhdd, каждый из 2k секторов, поэтому для любого кластера файловой системы optimun для чтения/записи будет 3x2k = 6k, но это невозможно на многих файловых системах, а затем подумайте, что если использовать размер кластера 64k, 64k/6k = 32/3, что вызывает несбалансированность, поэтому не оптимален и т.д. сделать математику, чтобы получить оптимальный размер кластера.</p><p>мои лучшие результаты следующие: размер кластера = размер полосы * количество дисков на полосе; таким образом, каждое чтение/запись имеет точный размер, который заставляет работать все диски, так что повышение скорости очень велико. пример размера кластера 192 кб для 3 дисков с размером полосы 64 кб; другой пример: размер кластера 192 кб для 6 дисков с размером полосы 32 кб.</p><p>и всегда не забывайте тестировать один диск в 4k, 8k, 16k, 32k, 64k блоке; многие диски дают действительно плохие скорости с меньшими числами, такими как 4k, но дают более чем в десять раз более быстрое время при 64k, 128k или выше.</p><p>да, использование кластеров большого размера может привести к потере места на кластере las каждого файла (если вы используете миллионы файлов по 1 байту каждый), лучше использовать компактную/pack-on-the-fly систему поверх файловой системы, например, диск размером 4 тб с размером кластера 4 кб может иметь только файлы размером менее 4 тб/4 кб = 1073741824 по 1 байт каждый, то есть всего 1 гб, если все файлы имеют размер 1 байт (размер кластера 4 кб), наихудшее соотношение размера кластера больше, но если файлы огромные, например, виртуальные машины (около 32 гб в качестве примера или всего несколько мегабайт), потерянные только на последнем кластере; такие большие файлы, большой размер кластера намного лучше для производительности, но будьте осторожны, как виртуальная машина использует это.</p><p>никто не скажет вам этот секрет: в гостевой системе не используйте размер кластера 4k, используйте тот же размер кластера, что и размер кластера, где находится виртуальный диск, или кратный ему.</p><p>да, я безумно стремлюсь получить максимальную скорость на гостевых дисках, поскольку, как я сказал, с 6 вращающимися дисками я получаю скорость около 1,7 гб/с, скорость шины sata iii является узким местом, а не самими дисками. я использую высокопроизводительные (не дешевые) диски, кэш 128 мб со скоростью записи 283 мб/с каждый.</p><p>для вас и для всех людей: гораздо лучше узнать, как размер кластера, размер полосы и размер блока должны быть связаны до проведения любого теста скорости, иначе тестирование lvm2 или любого другого raid (также zfs) может дать ложные выводы.</p><p>просто пример для этого: я тестирую время загрузки linux с 2x60 мб/с 2,5-дюймовыми дисками sata 5400 об/мин на материнской плате портов sata ii, а затем тестирую с 2xssd sata iii (они могут записывать более 250 мб/с каждый при подключении к sata iii порты), время загрузки занимает всего две секунды меньше, всего две секунды при пятиминутной загрузке, почему? поскольку большинство дисков начальной загрузки не используются, он выполняет операции с оперативной памятью и процессором, но не с операциями ввода-вывода.</p><p>всегда проверяйте то, что вы будете делать в реальном времени, а не только грубые скорости (другими словами, максимальная скорость).</p><p>максимальная скорость - это хорошо знать, что бит не может быть представлен, возможно, вы не используете диски на максимальной скорости 100% времени, ос и приложения должны выполнять операции на оперативной памяти и процессоре без ввода-вывода, поэтому в это время скорость диска не имеет значение вообще.</p><p>все говорят, что ssd значительно повышает скорость загрузки windows, на моих тестах это также ложь, только я доказал 28 секунд при времени загрузки около восьми минут.</p><p>так что, если вы мне нравитесь: копирование linux в оперативную память при загрузке, ssd не будет лучше, чем вращающиеся жесткие диски, я также протестировал флешку usb 3.1 gen2 (чтение 139 мб/с), время загрузки зависит только от нескольких секунд пять минут загрузки, почему? легко, чтение выполняется при копировании в оперативную память, если диск/ssd/usb-stick больше не используется на оставшейся части болта, данные находятся на оперативной памяти, как оперативная память.</p><p>теперь я продаю все свои ssd, которые у меня есть, они не улучшают копирование на оперативной памяти linux при загрузке, но их тестирование говорит, что они в 5 раз быстрее ... видите, тесты дают ложные выводы ... да, тестируйте и тестируйте реально рабочий день.</p><p>надеюсь, это может прояснить ситуацию с мужчинами ... lvm с плохими размерами кластеров и полосок влияет гораздо больше, чем накладные расходы слоя.</p>

<blockquote> <p>стоит ли добавить lvm на гостевую ос?</p> </blockquote><p>вы не должны этого делать, поскольку достаточно иметь файловую систему ext3 или ext 4 внутри логического тома хоста. нет необходимости добавлять еще одну группу томов, физический том и логический том внутри.</p>