https://slinkov.ru/openforum/vsluhforumID3/66462.html Сервис Facebook уже не первый раз открывает свои наработки в области высокопроизводительных систем и Linux, на этот раз решено поделиться наработками в области ускорения (http://www.facebook.com/note.php?note_id=388112370932) работы сервера MySQL и других интенсивно взаимодействующих с диском приложений, за счет организации процесса прозрачного кэширования данных на быстрых SSD-накопителях.<br><br><br>Как известно, если у движка хранилища данных InnoDB рабочий набор данных не умещается в пуле кэша, тогда отзывчивость (latency) операций чтения сильно ухудшается. Эту проблему можно решить, если расположить рабочий набор данных на более быстром носителе информации, например, на SSD дисках. Модуль Flashcache (http://github.com/facebook/flashcache), созданный инженерами Facebook, занимается именно этой задачей - он работает как универсальных механизм кэширования для любого приложения, работающего с блочным устройством.<br><br><br>Также Flashcache увеличивает (http://github.com/facebook/flashcache/blob/ma...<br><br>URL: http://www.fac https://slinkov.ru/openforum/vsluhforumID3/66462.html#43 Sun, 02 May 2010 18:52:49 GMT &gt;Единственно, что мне жутко не хватает в Линукс - это jail,<br><br>Странно, учитывая что openvz сделали явно не вчера. Может быть, ручник стоит отпускать побыстрее? oO<br> https://slinkov.ru/openforum/vsluhforumID3/66462.html#42 Sun, 02 May 2010 16:38:41 GMT Ну так фэйсбуковцы вроде ж и предлагают кешить нагрузку где в основном чтение?<br> https://slinkov.ru/openforum/vsluhforumID3/66462.html#41 Sat, 01 May 2010 21:38:02 GMT &gt;&gt; Я думала, тут вы запоете в очередной раз песню про чексуммы данных в zfs, и то, то hw-контроллеры не проверяют непосредственно данные, а только блоки данных в raid5/6, но, похоже, Вы про это не знали :)<br>&gt;<br>&gt;С вами все ясно. Задуматься вы не задумались, а вместо этого начали <br>&gt;скатываться в направлении "сам дурак", поэтому продолжать с вами дискуссию не <br>&gt;вижу смысла <br><br>А задумывались ли Вы так ли хороша и универсальна zfs, как Вы пытаетесь показать всем в каждой теме(по-моему, большинство дисскуссий в которых Вы учавствуете, касаются ZFS)? <br><br>Погуглив по Вашим ответам заранее, мне было с самого начала понятно, что Вы работаете на публику. Если бы Вы погуглили по моим ответам на этом форуме, могли бы заметить, что с моей стороны всегда вызывает острое неприятие, и даже контр-агрессию желание собеседника навязать некую "супер-бупер" технологию(даже если я ее уже использую, и кому-то рекомендую) в качестве некоего универсального "филосовского камня", который решит все мои жизненные проблемы, и проблемы ос https://slinkov.ru/openforum/vsluhforumID3/66462.html#40 Sat, 01 May 2010 21:17:17 GMT &gt; Я думала, тут вы запоете в очередной раз песню про чексуммы данных в zfs, и то, то hw-контроллеры не проверяют непосредственно данные, а только блоки данных в raid5/6, но, похоже, Вы про это не знали :)<br><br>С вами все ясно. Задуматься вы не задумались, а вместо этого начали скатываться в направлении "сам дурак", поэтому продолжать с вами дискуссию не вижу смысла<br> https://slinkov.ru/openforum/vsluhforumID3/66462.html#39 Sat, 01 May 2010 20:47:27 GMT &gt;&gt; Если диски не битые, то без разницы<br>&gt;<br>&gt;Ну почему же: на одном могут быть правильные данные, на другом - <br>&gt;нет, так что разница есть - в одном случае вы исправите <br>&gt;плохую копию и восстановите избыточность, в другом - уничтожите последнюю хорошую. <br>&gt;<br>&gt;<br>&gt;&gt; если ФС сверху журналируемая, ничего плохого не произойдет<br>&gt;<br>&gt;см. пример выше; вдруг это произойдет для блока журнала? <br><br>Не бывает плохих или хороших данных для зеркала. Зеркало вообще не проверяет консистентность блоков данных и метаданных! Если метаданные различаются, рейд ресинкается, и все (других вариантов нет)<br><br>Вы в любой момент можете изъять из зеркала любую из его половин, и ничего не потеряете, так как на обе половины консистентны.<br><br>Более того, на другая половина так же консистентна :) "Правильные данные" и зеркало это совершенно перепендикулярные понятия, оно вообще не проверяет блоки между дисками на консистентность.<br><br>В любой момент(после жесткого сброса) можно засинкать любую из половин о другую, и ничего не потерять.<br><br>Именно https://slinkov.ru/openforum/vsluhforumID3/66462.html#38 Sat, 01 May 2010 20:26:25 GMT &gt; Если диски не битые, то без разницы<br><br>Ну почему же: на одном могут быть правильные данные, на другом - нет, так что разница есть - в одном случае вы исправите плохую копию и восстановите избыточность, в другом - уничтожите последнюю хорошую.<br><br>&gt; если ФС сверху журналируемая, ничего плохого не произойдет<br><br>см. пример выше; вдруг это произойдет для блока журнала?<br><br>&gt; и вообще зеркало рулит (на ряде задач, если не толкать его фанатично в каждую дырку, как это делают фанатики с zfs)<br><br>Зеркало действительно неплохой вариант во многих случаях, а зеркало в его реализации в ZFS - неплохой вдвойне, и вовсе не потому, что с ним носятся фанатики.<br><br>&gt; Извините, я уже и так достаточно много рассказала, чего Вы, по всей видимости, не знали(должно быть стыдно, так как азы :)) ).<br><br>А вы забавная. Я ведь даже не просил все это рассказывать - все это расписано в документации, книжках и так далее. Я всего лишь задавал вопросы, рассчитывая, что они заставят вас задуматься. Видимо, пока не заставили.<br><br>&gt; Не поняла вопроса : https://slinkov.ru/openforum/vsluhforumID3/66462.html#37 Sat, 01 May 2010 17:44:18 GMT &gt;&gt; Если жесткий сброс по питанию, софт-зеркало поднимется после синка одной половинки о другую<br>&gt;<br>&gt;Остается открытым вопрос, какую половину выбрать в качестве источника данных для синхронизации <br><br>Если диски не битые, то без разницы: на один диск последний флэш был на одну секунду раньше, а на другой на одну секунду позже, и что?<br>Все равно при сбросе питания рабочие данные в приложениях были утеряны(велика ли разница, на одну секунду туда, или сюда?), если ФС сверху журналируемая, ничего плохого не произойдет. То же и в случае с innodb/postgre/и пр. бд с журналами.<br>В UFS без всяких журналов(через geom) и myisam можно в любом случае получить проблемы, вне зависимости от наличия BBU<br><br>В общем, тезис: bbu для зеркала не нужен(нет, конечно кто-то может не желать ждать на тех же SATA под нагрузкой 5-6 часов, пока оно досинкается, в этом случае BBU оправдано, но вообще это не нормально, если сервер часто сбрасывается по питанию), и вообще зеркало рулит (на ряде задач, если не толкать его фанатично в каждую дырк https://slinkov.ru/openforum/vsluhforumID3/66462.html#36 Sat, 01 May 2010 17:35:21 GMT &gt; Если жесткий сброс по питанию, софт-зеркало поднимется после синка одной половинки о другую<br><br>Остается открытым вопрос, какую половину выбрать в качестве источника данных для синхронизации<br><br>&gt; а в рейдах с проверкой четности, исправлена ошибка, при ее наличии<br><br>Каким образом? Предположим, что при проверке четности полоски RAID была обнаружена ошибка этой самой четности. Как определить, какой из дисков нужно исправлять?<br><br>&gt; Главная проблема zfs то, то она не параллельная, и тем более не кластерная<br><br>Вопрос был более локального характера - о скорости RAID-Z и о том, насколько он подходит для разных классов задач. А не о том, что ZFS - локальная файловая система. RAID-Z действительно может быть тем еще тормозом на определенных задачах, и показывать более чем приличную производительность и стоимость хранения на других. Каких, знаете?<br> https://slinkov.ru/openforum/vsluhforumID3/66462.html#35 Sat, 01 May 2010 16:58:58 GMT &gt;&gt;[оверквотинг удален]<br>&gt;&gt;<br>&gt;&gt;То есть решение получается нежизнеспособное, если даже способа определить, какой диск с <br><br>З.Ы. Это все лирика, и в любом случае, в реальной ситуации mirror и пятый рейд на порядки надежнее, чем одиночный диск любого типа, но пятого рейда лучше либо избегать, либо хорошо бэкапить, так как риск развала во время синка действительно существеннен<br><br>З.З.Ы. забавляет, как фанатики носятся с проверкой четности _данных_ на файловой системе, но при этом используют PC-систему без ECC памяти, часто откровенно кривой и несертифицированный софт, написанный на пых-пыхе студентом без какого-то адекватного коммюнити, но зато сверху "православной" ZFS, а бэкапы у нас на соседний диск, который сгорает вместе с ДЦ hosting.ua :)<br>