Во-первых, у Intel не софтовое ускорение, а такое же аппаратное(SSE инструкции и проч).
Во-вторых, утверждение: «Всегда (подчёркиваем, ВСЕГДА) ФОП (Функционально ориентированные процессоры) превосходят процессоры общего назначения для узкоспециализированных задач.», не корректно, если вычислительная часть не является узким местом. 24 ядера Intel(2 сокета например) вполне вероятно справятся с задачей расчета crc32(который аппаратно ускорен).
И при чем тут ZFS? В статье идет речь о блочном вводе выводе, а не файловом. Учите теорию систем хранения, господа комментаторы….
Наверху любого блочного устройства лежат, либо ФС, либо специализированные LVM(например Oracle ASM).
Надо признать, для второго как раз дедупликация могла бы быть полезна, но по факту не будет, ибо одинаковые блоки в БД большая редкость. Сжатие, прозрачное как в IBM Storwize(обычные Intel ядра к слову) например тут поможет.
Неважно какой в автомобиле двигатель, если мы соревнуемся на 1/4 мили. Важен результат.
Не возможно, а точно возрастет. Он действительно жмет некоторыми кусками(chunk). Но я точно не знаю перечитывает ли он полностью эти чанки или нет и в каких случаях. Поэтому не понятно на сколько возрастет.
Тут еще имеет влияние в каком месте чанка лежит блок и тому подобные параметры.
Именно поэтому данный тест я проводил с линейным последовательным чтением.
Интерес к данному подходу может быть в первую очередь у баз направленности DSS, DHW, OLAP и еже с ними.
Вы имеете ввиду кэш ОС или так называемый buffer cache постгреса?
Если первое, то я написал как исключить его влияние:
Перед каждым запуском сбрасываем pagecache с помощью команды:
free && sync && echo 3 > /proc/sys/vm/drop_caches && free
Эта команда сбрасывает линуксовый кэш, да если этого не сделать, все последующие запросы ускоряются на порядки, ибо все лежит в RAM, а его у нас 48ГБ.
На счет второго все еще проще, его размер по умолчанию чрезвычайно мал(128МБ) чтобы вносить хоть какие-либо погрешности.
Его я специально оставил нетронутым.
К тому же, я каждый раз перед запуском теста перезапускал инстанс, ибо заново восстанавливал всю БД.
Кстати в новых версиях постгреса планируют внедрить directIO как у oracle, чтобы 2 раза не кэшировать одни и те же данные, плюс сделать процесс кэширования более оптимальным.
Нет, это невозможно по определению. ФС и БД не взаимодействуют на таком уровне.
БД просто отдает кусок данных и его же запрашивает, что дальше с ним делает ФС она не знает.
Не заработает это еще по одной причине:
Все БД так работают, что минимальный объект доступа это некоторый блок(8192 в данном случае).
В блоке хранится несколько строк и в любом случае, самая дорогая операция — чтение/запись с/на диск происходит полным куском.
И даже если вам нужно всего лишь изменить в одном гипотетическом поле цифру 1 на цифру 0, то вы сначала прочитаете 8192 байта с диска(если этого блока нет в кэше БД, либо в кэше ОС, если последняя не использует directIO), сделаете необходимые изменения и обратно запишите 8192 байта.
На этом фоне, процессорным временем по разархивированию этих 8192 байт зачастую можно пренебречь.
Диски в подавляющем большинстве случаев выступают бутылочным горлышком, а при наличии аппаратного ускорения, операции компрессии и декомпрессии тем паче не являются критической нагрузкой на ЦП.
Вы можете указывать конкретно что сжимать, а что нет.
Если вы монтируете фс с опцией сжатия, то сжимается по умолчанию все.
Но можно на существующей ФС сжать уже имеющиеся данные на лету например вместе с дефрагментацией.
Конкретную папку или конкретный файл.
Возможности достаточно гибкие.
Стабильной надежности и цены бы не было.
Не уловил, а при чем тут cow?
И про какой cow идет речь.
У нас есть несколько вариантов:
fs(cow) — lvm — bldev
fs — lvm(cow) — bldev
fs — lvm — bldev(cow)
Любой из этих вариантов для сколь-либо важной бд неприемлем разумеется, ибо ни какой из этих уровней про внутреннюю структуру БД ничего не знает, а значит логическую целостность мы не гарантируем.
Но есть сценарии, когда в тестовой-девелоперской среде, для создания снэпшотов оно может быть использовано с пользой для дела. Хотя для этого хватает cow на других уровнях.
И раз зашел разговор про это, имели ли вы положительный опыт использования встроенного lvm в какой-либо фс, например zfs?
Started with simply adding more compression algorithms, like LZ4, that itself does not bring a significant improvement without other changes.
Там комплекс необходимых улучшений, которые должны дать некоторое улучшение.
Сейчас, даже такое сжатие выглядит вполне приемлемым по описанному сценарию.
Думаю стоит все же немного подождать до LZ4.
Сейчас гораздо перспективнее на мой взгляд исследовать случайный доступ, а именно UPDATE(SELECT-DELETE-INSERT), в случайном порядке размазанных по таблице данных.
Имитируя тем самым некий OLTP. Это покажет возможную перспективу использования, ко времени, когда он станет действительно стабильной.
Ну, в реальной жизни сие может быть весьма полезным.
Например, если у нас 40ТБ архивных данных, которые никогда не меняются, а храним мы их на медленных дисках, ибо на дорогих у нас активная БД, ситуация меняется в корне.
Мы сходу можем получить 10 ТБ, которые можно уместить и на быстрых дисках тем самым ускорив некоторую аналитику.
Я общем-то и написал что оно не применимо ко всему подряд, ибо я даже не проверял пока.
Данное тестирование конечно нельзя назвать полным, ибо задействовано только чтение и то линейное.
И это не считая его нестабильности о чем пишут ниже.
Не совсем так, количество обращений может быть большим, вопрос только в том какого характера.
Линейные чтения, то бишь всякая аналитика и прочий dwh сильно ускоряются.
Если смотреть iostat(и если он правильно считает в данном случае), количество мегабайт в секунду сокращается пропорционально фактору сжатия. А это сниженная нагрузка на СХД.
Надо провести тесты на случайную запись.
Хотя, в любом случае надо ждат пока ФС станет стабильным, иначе страшно его использовать так.
У меня такое ощущение, что люди путают причинно-следственную связь.
Пока политика не пришла в интернет, он был свободен.
Глупость скажу, но может попробовать игнорировать таких придурей как навальный и причин для блокировок не будет?
Президент самой большой в мире страны, 1/6 части суши, в перерывах между всевозможными встречами, в перелетах сидит и рассуждает как бы ему еще заработать на фьючерсах.
А то за 13 лет ему не хватило наворованных денег и вот в свои 61 год, поддерживаемый подавляющим большинством народа, но все еще не удовлетворенным. Страдает от того, что не дополучил в прошлом месяце 100 миллиардов фантиков. Интересно, что он хочет купить на такие деньги.
И тут кроется самая большая для меня загадка.
Вор Путин или нет, его поддерживает абсолютное большинство народа. С другой стороны поддержка Путина на хабре это хабрасуицид. То бишь демократия казалось бы торжествует, но некоторое меньшинство желает его головы на пике.
И при этом паттерн поведения меньшинства во многом идентичен: Выйти на улицу и что есть мочи крикнуть: «Вооор!», «Рассист», «Сексист», «Гомофоб».
Не предлагая ничего и ни за что не отвечая.
Ваш враг Россия не пострадает нисколько от того, что маск не закупит несколько двигателей.
Как выразился ваш земляк выше — «бензоколонка» — живет за счет других источников.
Это самая что ни на есть дешевая политика.
Показать воякам американским отмывающим деньги, что он свой.
Вот что говорит вики на тему того, что такое компьютер:
«устройство или система, способное выполнять заданную, чётко определённую изменяемую последовательность операций. Это чаще всего операции численных расчётов и манипулирования данными, однако сюда относятся и операции ввода-вывода.»
Чем мозг не компьютер.
Да и потом, Вам не приходила мысль, что в будущем компьютеры станут радикально иного толка.
>> Текущая вода МОЖЕТ использоваться
Что за бред?
Много чего может или не может. Суть в том, что мозг это делает, здесь и сейчас.
Мозг уже является вычислительным устройством.
Человеческий мозг обрабатывает информацию, — стало быть компьютер.
А изменения, которые происходят в нейронных связях есть ничто иное как результат программирования довольно высокого уровня.
«просто записывайте свои сны и скоро вы сможете запоминать их без усилий Смысл — научить мозг не забывать сны.»
Во-вторых, утверждение: «Всегда (подчёркиваем, ВСЕГДА) ФОП (Функционально ориентированные процессоры) превосходят процессоры общего назначения для узкоспециализированных задач.», не корректно, если вычислительная часть не является узким местом. 24 ядера Intel(2 сокета например) вполне вероятно справятся с задачей расчета crc32(который аппаратно ускорен).
Наверху любого блочного устройства лежат, либо ФС, либо специализированные LVM(например Oracle ASM).
Надо признать, для второго как раз дедупликация могла бы быть полезна, но по факту не будет, ибо одинаковые блоки в БД большая редкость. Сжатие, прозрачное как в IBM Storwize(обычные Intel ядра к слову) например тут поможет.
Неважно какой в автомобиле двигатель, если мы соревнуемся на 1/4 мили. Важен результат.
Тут еще имеет влияние в каком месте чанка лежит блок и тому подобные параметры.
Именно поэтому данный тест я проводил с линейным последовательным чтением.
Интерес к данному подходу может быть в первую очередь у баз направленности DSS, DHW, OLAP и еже с ними.
Если первое, то я написал как исключить его влияние:
Эта команда сбрасывает линуксовый кэш, да если этого не сделать, все последующие запросы ускоряются на порядки, ибо все лежит в RAM, а его у нас 48ГБ.
На счет второго все еще проще, его размер по умолчанию чрезвычайно мал(128МБ) чтобы вносить хоть какие-либо погрешности.
Его я специально оставил нетронутым.
К тому же, я каждый раз перед запуском теста перезапускал инстанс, ибо заново восстанавливал всю БД.
Кстати в новых версиях постгреса планируют внедрить directIO как у oracle, чтобы 2 раза не кэшировать одни и те же данные, плюс сделать процесс кэширования более оптимальным.
БД просто отдает кусок данных и его же запрашивает, что дальше с ним делает ФС она не знает.
Не заработает это еще по одной причине:
Все БД так работают, что минимальный объект доступа это некоторый блок(8192 в данном случае).
В блоке хранится несколько строк и в любом случае, самая дорогая операция — чтение/запись с/на диск происходит полным куском.
И даже если вам нужно всего лишь изменить в одном гипотетическом поле цифру 1 на цифру 0, то вы сначала прочитаете 8192 байта с диска(если этого блока нет в кэше БД, либо в кэше ОС, если последняя не использует directIO), сделаете необходимые изменения и обратно запишите 8192 байта.
На этом фоне, процессорным временем по разархивированию этих 8192 байт зачастую можно пренебречь.
Диски в подавляющем большинстве случаев выступают бутылочным горлышком, а при наличии аппаратного ускорения, операции компрессии и декомпрессии тем паче не являются критической нагрузкой на ЦП.
Если вы монтируете фс с опцией сжатия, то сжимается по умолчанию все.
Но можно на существующей ФС сжать уже имеющиеся данные на лету например вместе с дефрагментацией.
Конкретную папку или конкретный файл.
Возможности достаточно гибкие.
Стабильной надежности и цены бы не было.
И про какой cow идет речь.
У нас есть несколько вариантов:
fs(cow) — lvm — bldev
fs — lvm(cow) — bldev
fs — lvm — bldev(cow)
Любой из этих вариантов для сколь-либо важной бд неприемлем разумеется, ибо ни какой из этих уровней про внутреннюю структуру БД ничего не знает, а значит логическую целостность мы не гарантируем.
Но есть сценарии, когда в тестовой-девелоперской среде, для создания снэпшотов оно может быть использовано с пользой для дела. Хотя для этого хватает cow на других уровнях.
И раз зашел разговор про это, имели ли вы положительный опыт использования встроенного lvm в какой-либо фс, например zfs?
Там комплекс необходимых улучшений, которые должны дать некоторое улучшение.
Сейчас, даже такое сжатие выглядит вполне приемлемым по описанному сценарию.
Думаю стоит все же немного подождать до LZ4.
Сейчас гораздо перспективнее на мой взгляд исследовать случайный доступ, а именно UPDATE(SELECT-DELETE-INSERT), в случайном порядке размазанных по таблице данных.
Имитируя тем самым некий OLTP. Это покажет возможную перспективу использования, ко времени, когда он станет действительно стабильной.
Или он настолько крив, что даже в таком случае может посыпаться?
Например, если у нас 40ТБ архивных данных, которые никогда не меняются, а храним мы их на медленных дисках, ибо на дорогих у нас активная БД, ситуация меняется в корне.
Мы сходу можем получить 10 ТБ, которые можно уместить и на быстрых дисках тем самым ускорив некоторую аналитику.
Я общем-то и написал что оно не применимо ко всему подряд, ибо я даже не проверял пока.
И это не считая его нестабильности о чем пишут ниже.
Линейные чтения, то бишь всякая аналитика и прочий dwh сильно ускоряются.
Если смотреть iostat(и если он правильно считает в данном случае), количество мегабайт в секунду сокращается пропорционально фактору сжатия. А это сниженная нагрузка на СХД.
Надо провести тесты на случайную запись.
Хотя, в любом случае надо ждат пока ФС станет стабильным, иначе страшно его использовать так.
Например в RHEL 6u6 ядро 2.6.32, хотя надо признать в 7-ке уже 3.10.
У меня такое ощущение, что люди путают причинно-следственную связь.
Пока политика не пришла в интернет, он был свободен.
Глупость скажу, но может попробовать игнорировать таких придурей как навальный и причин для блокировок не будет?
А то за 13 лет ему не хватило наворованных денег и вот в свои 61 год, поддерживаемый подавляющим большинством народа, но все еще не удовлетворенным. Страдает от того, что не дополучил в прошлом месяце 100 миллиардов фантиков. Интересно, что он хочет купить на такие деньги.
И тут кроется самая большая для меня загадка.
Вор Путин или нет, его поддерживает абсолютное большинство народа. С другой стороны поддержка Путина на хабре это хабрасуицид. То бишь демократия казалось бы торжествует, но некоторое меньшинство желает его головы на пике.
И при этом паттерн поведения меньшинства во многом идентичен: Выйти на улицу и что есть мочи крикнуть: «Вооор!», «Рассист», «Сексист», «Гомофоб».
Не предлагая ничего и ни за что не отвечая.
Ваш враг Россия не пострадает нисколько от того, что маск не закупит несколько двигателей.
Как выразился ваш земляк выше — «бензоколонка» — живет за счет других источников.
Это самая что ни на есть дешевая политика.
Показать воякам американским отмывающим деньги, что он свой.
«устройство или система, способное выполнять заданную, чётко определённую изменяемую последовательность операций. Это чаще всего операции численных расчётов и манипулирования данными, однако сюда относятся и операции ввода-вывода.»
Чем мозг не компьютер.
Да и потом, Вам не приходила мысль, что в будущем компьютеры станут радикально иного толка.
Что за бред?
Много чего может или не может. Суть в том, что мозг это делает, здесь и сейчас.
Мозг уже является вычислительным устройством.
А изменения, которые происходят в нейронных связях есть ничто иное как результат программирования довольно высокого уровня.
«просто записывайте свои сны и скоро вы сможете запоминать их без усилий Смысл — научить мозг не забывать сны.»
i.imgur.com/4GU7kg7.png