Выключение atime в файловой системе
mutt, почтовый клиент, времена доступа к файлу использования для контроля для новой почты, прибывающей в mbox-отформатированный почтовый ящик. По-видимому, эта проблема не серьезна, и легка работать вокруг.
Кроме этого, трудно найти примеры вещей тем повреждением на noatime. Я выполняю много серверов Linux с noatime во всех файловых системах, и я не могу вспомнить когда-либо видевший проблемы, относящиеся к noatime.
Если Вы обеспокоены использованием noatime в целом Вы могли посвятить отдельную файловую систему для своего материала mongoDB и смонтировать только ту файловую систему с noatime.
Править
Я нашел интересный блог по kerneltrap.org, который заключает некоторые обсуждения в кавычки между разработчиками Linux (Linus Torvalds, Ingo Molnar, Alan Cox и другие) по теме atime. Во втором электронном письме Ingo он говорит это:
... у меня нет реальной жалобы на ext3 - с обязательной квалификацией, которая "noatime, nodiratime" в/etc/fstab является необходимостью. Это ускоряет вещи очень явно - особенно, когда к большому количеству файлов получают доступ. Довольно странно, что каждый рабочий стол Linux и сервер повреждены значимым замедлением производительности IO из-за постоянных обновлений atime, в то время как существует всего два реальных пользователя его: tmpwatch [который может быть настроен для использования ctime, таким образом, это не большая проблема] и некоторые резервные инструменты. (Хорошо, и почта - уведомляет также, что я предполагаю.) Из десятков тысяч приложений. Таким образом для большинства рабочих нагрузок файла мы даем Windows 20%-30%-й край производительности почти для ничего.
Инструменты, которые опрашивают относительно использования файла, такого как временные инструменты для очистки файла, используют его. Можно обойти это в некоторых файловых системах и Ose при помощи relatime вместо этого, который только обновляет atime после того, как определенная продолжительность передала, так как это обновилось.
Вы могли также создать отдельную точку монтирования для своего mongoDB набора копии. Можно затем установить noatime paramtere на той точке монтирования только, не влияя ни на какие другие программы.
Как продолжение здесь, relatime было сделано по умолчанию в ядре в 2.6.30, которое было выпущено примерно в марте 2009 года. Это означает, что выгоды от настроек noatime будут меньше на любом современном ядре.
Это по-прежнему рекомендация, потому что MongoDB по-прежнему дает прирост производительности, но пока вы используете достаточно актуальную версию ядра, это не так важно, как раньше.
Кроме того, вдобавок к упомянутому здесь программному обеспечению, я также видел время, используемое средствами резервного копирования.
Я просто хотел бы подчеркнуть один момент @Steven Monday - используйте отдельную файловую систему.
Для базы данных это всегда хороший вариант и дает вам гораздо больше гибкости в настройке базы данных. производительность при незначительных неудобствах, связанных с дополнительной точкой монтирования. Обычно дает вам больше возможностей для создания моментального снимка базы данных для резервного копирования (даже более удобно в тех случаях, когда вы можете сделать снимок и сделать резервную копию реплики вместо главной)