MongoDB и наборы данных, которые не вписываются в оперативную память независимо от того, насколько сильно вы забиваете

Это очень зависит от системы, но есть вероятность, что мы приблизимся к какому-то произвольному обрыву и перейдем в Real Trouble. Мне любопытно, какие существуют правила для хорошего ОЗУ для дискового пространства. Мы планируем следующий раунд систем, и вам нужно сделать некоторые выбор в отношении ОЗУ, SSD и о том, сколько из них получит новые узлы.

Но теперь для некоторых деталей производительности!

Во время обычного рабочего процесса одного проекта, MongoDB попадает с очень высоким процентом записей (70-80%). Как только наступает второй этап обработки, он чрезвычайно читается, поскольку ему необходимо дедуплицировать записи, идентифицированные в первой половине обработки. Это рабочий процесс, для которого «держите свой рабочий набор в ОЗУ», и мы разрабатываем вокруг этого предположения.

Весь набор данных постоянно обрабатывается случайными запросами из исходных источников конечного пользователя; хотя частота нерегулярна, размер обычно довольно небольшой (группы из 10 документов). Поскольку это зависит от пользователя, ответы должны находиться под порогом «скучно-сейчас» 3 секунды. Этот шаблон доступа гораздо менее вероятен в кеше, поэтому очень вероятно, что он понесет хиты диска.

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

Готовые размеры документа сильно различаются, но размер медианный составляет около 8K.

Высокочитаемая часть обычной обработки проекта настоятельно предлагает использовать Replicas для распространения трафика Read. Я прочитал в другом месте , что 1:10 RAM-GB для HD-GB является хорошим правилом большого пальца для медленного диски. Поскольку мы серьезно рассматриваем возможность использования гораздо более быстрых SSD, я бы хотел знать, существует ли аналогичное эмпирическое правило для быстрых дисков.

Я знаю, что мы используем Mongo таким образом, чтобы кэш-память действительно не собиралась летать, поэтому я ищу способы разработки системы, которая может выдержать такое использование. Набор данных whole , вероятно, будет больше всего TB в течение полугода и будет расти.

12 голосов | спросил sysadmin1138 16 J000000Monday12 2012, 15:32:59

3 ответа


5

Это будет куча мелких очков. К сожалению, нет однозначного ответа на ваш вопрос.

MongoDB позволяет ядру ОС обрабатывать управление памятью. Помимо того, что при задании проблемы возникает как можно больше оперативной памяти, есть всего несколько вещей, которые можно сделать для «активного управления» вашим рабочим набором.

Единственное, что вы можете сделать для оптимизации записи, - это первый запрос для этой записи (сделать чтение), чтобы она работала в рабочей памяти. Это позволит избежать проблем с производительностью, связанных с глобальным блокировщиком всей процедуры (который должен стать per-db в версии 2.2)

Не существует жесткого правила для соотношения RAM и SSD, но я думаю, что необработанные IOPS SSD должны позволить вам идти с гораздо меньшим коэффициентом. С головы до головы, 1: 3, вероятно, самый низкий, с которым вы хотите пойти. Но, учитывая более высокие затраты и более низкую производительность, вам, вероятно, придется поддерживать это соотношение в любом случае.

Что касается «Write vs Reading phase», я правильно читаю, что как только запись записывается, она редко обновляется («upserted»)? Если это так, может быть целесообразно разместить два кластера; обычный кластер записи и оптимизированный для чтения кластер для «старых» данных, которые не были изменены в [X период времени] . Я бы определенно включил чтение ведомого на этом кластере. (Лично я бы это сделал, включив модифицированное по дате значение в объектные документы вашего db.)

Если у вас есть возможность загрузить тест перед тем, как войти в Prod, перфорируйте его до конца. MongoDB был написан с предположением, что он часто будет развернут в виртуальных машинах (их системы ссылок находятся в EC2), поэтому не бойтесь обманывать виртуальные машины.

ответил gWaldo 16 J000000Monday12 2012, 16:20:22
13

Это предназначено в качестве добавления к другим ответам, размещенным здесь, в которых обсуждаются многие из соответствующих элементов, которые будут рассмотрены здесь. Однако есть еще один, часто упускаемый из виду фактор, когда дело доходит до эффективного использования ОЗУ в системе типа произвольного доступа - readahead.

Вы можете проверить текущие настройки readahead (в Linux), запустив blockdev --report (обычно требуется привилегии sudo /root). Это выведет таблицу с одной строкой для каждого дискового устройства. Столбец RA содержит значение для readahead. Это значение представляет собой число секторов с 512 байтами (если размер сектора не является значением по умолчанию), обратите внимание на то, что на момент написания этого сообщения, даже диски с большими размерами обрабатываются ядром как 512-байтовые сектора), которые читаются на каждом доступ к диску.

Вы можете установить параметр readahead для данного дискового устройства, выполнив:

blockdev --setra <value> <device name>

При использовании программной RAID-системы обязательно установите readahead на каждом диске, а также на устройстве, которое соответствует RAID-контроллеру.

Почему это важно? Ну, readahead использует тот же ресурс, который MongoDB пытается использовать, чтобы оптимизировать ваши чтения для последовательного доступа - ОЗУ. Когда вы делаете последовательные чтения на вращающихся дисках (или устройствах, которые ведут себя как вращающиеся диски в любом случае), EBS я смотрю на вас), выборка близлежащих данных в ОЗУ может значительно увеличить производительность, избавить вас от искажений и высокой настройки readahead в правильная среда может дать вам впечатляющие результаты.

Для такой системы, как MongoDB, где ваш доступ, как правило, будет случайным доступом к набору данных, это просто растрачивает память, которая лучше всего используется в других местах. Система, которая, как упоминалось ранее, также управляет памятью для MongoDB, собирается выделять кусок памяти для чтения, когда она запрашивается, и, следовательно, не позволяет эффективно использовать RAM для MongoDB.

Выбор правильного размера readahead является сложным и зависит от вашего оборудования, конфигурации, размера блока, размера полосы и самих данных. Если вы перейдете на SSD, например, вам понадобится низкая настройка, но насколько низкая будет зависеть от данных.

Чтобы объяснить: вы хотите удостовериться, что readahead достаточно высок, чтобы вытащить полный отдельный документ и не нужно возвращаться на диск. Возьмем ваш средний медиану размером 8 тыс. - так как секторы на диске, как правило, 512 байт, для чтения всего документа без чтения требуется 16 обращений к диску. Если у вас есть чтение из 16 секторов или более, вы читали бы весь документ только с одной поездкой на диск.

На самом деле, поскольку индексы индекса MongoDB равны 8k, вы никогда не захотите установить readahead ниже 16 в любом случае, или для чтения в одном индексном ковше потребуется 2 обращения к диску. Общей практикой является начало вашей текущей настройки, ее уменьшение вдвое, а затем переоценка использования ОЗУ и ввода-вывода и переход оттуда.

ответил Adam C 16 J000000Monday12 2012, 19:34:34
3

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

Используя правило управления 1:10, вы смотрите примерно на 128 ГБ оперативной памяти для 1 ТБ дискового хранилища; В то время как некоторые доступные SSD сегодня утверждают, что они достигают> 60K IOPS, цифры в реальном мире могут немного отличаться, а также от того, используете ли вы RAID с вашими твердотельными накопителями или нет, а если вы, то RAID-карта чрезвычайно важна, поскольку хорошо.

Во время этого поста, исходя из 128 ГБ DDR3 ECC-RAM до 256 ГБ, похоже, на сервере Intel 1U требуется около 2000 $, и это даст вам соотношение 1: 5 с 1 ТБ данных, которые я чувствую было бы еще лучше. Если вам нужно, чтобы ваша рабочая нагрузка была завершена как можно быстрее, больше оперативной памяти определенно поможет, но действительно ли это срочно?

Вам нужно будет также настроить некоторую настройку файловой системы, например, «noatime, data = writeback, nobarrier» на ext4, и вам может понадобиться внести некоторые настройки настроек ядра, чтобы выжать максимум производительности, которую вы можете из вашей системы.

Если вы собираетесь с RAID, RAID-10 будет довольно хорошим выбором, а с правильным RAID-контроллером будет предлагаться довольно мощный прирост производительности, но вдвое уменьшите доступное пространство. Вы также можете посмотреть в RAID50, если хотите добиться достойного повышения производительности, не сократив вдвое доступное пространство. Риск запуска RAID заключается в том, что у вас больше нет доступа к TRIM на ваших дисках, а это означает, что вам нужно время от времени извлекать данные, разбивать RAID, TRIM на диски и воссоздавать RAID.

В конечном счете вам нужно решить, какую сложность вы хотите, сколько денег вы хотите потратить и как быстро вы хотите обработать свою рабочую нагрузку. Я бы также оценил, является ли MongoDB идеальной базой данных для использования, поскольку вы все еще можете использовать Mongo для запросов конечных пользователей, которым нужны быстрые ответы, но использовать что-то еще для обработки ваших данных, которые не нужно быть готовыми за несколько секунд , и это также может облегчить вам распространение вашей рабочей нагрузки на нескольких машинах.

ответил gekkz 16 J000000Monday12 2012, 16:33:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132