Как ускорить rsync / tar большого Maildir?

откройте терминал и сделайте как

sudo kate /etc/default/grub

, затем найдите эту строку и измените, как показано ниже

GRUB_CMDLINE_LINUX_DEFAULT="text"

, теперь закройте редактор и сделайте как

и перезапустить сейчас

7
задан 22 July 2011 в 04:05

18 ответов

В итоге я написал небольшой скрипт python для вычисления корреляции между именами каталогов и inodes, inodes и блоками данных, а также именами каталогов для блоков данных. Оказывается, что ext4 имеет тенденцию иметь довольно плохую корреляцию между порядком, в котором имена файлов появляются в каталоге, и где они хранятся на диске. Обсудив его в списке рассылки ext4, выясняется, что это результат хешированных индексов каталога, используемых для ускорения поиска в больших каталогах. Имена хранятся в хэш-порядке, который эффективно скремблирует их порядок по отношению к чему-либо еще.

Мне кажется и, по крайней мере, еще одному комментатору, что это недостаток в fs, который должен быть исправлен. Тед Ц'о (сторонник экстренной службы) считает, что в fs будет слишком сложно сделать так, что хорошие инструменты (например, rsync и tar) должны иметь возможность сортировать каталог по номеру inode перед чтением файлов.

Таким образом, похоже, что запросы на повышение характеристик нужны для rsync и tar.

7
ответ дан 25 May 2018 в 22:36
  • 1
    Спасибо, что поделились своими результатами. Похоже на информацию, которая может пригодиться в один прекрасный день. – andol 23 March 2011 в 22:30
  • 2
    Я должен согласиться с Тедом Цо, что производительность для этого варианта использования должна быть исправлена ​​на уровне приложений. Нет оснований полагать, что данные файла должны храниться в алфавитном порядке на устройстве хранения. Если какое-либо другое приложение хочет читать файлы в порядке последнего времени модификации, fs не может выполнять обе операции с высокой скоростью в любом случае. – Mikko Rantalainen 11 April 2014 в 13:51
  • 3
    @MikkoRantalainen, это не о том, какой произвольный заказ приложение «хочет», но какой лучший порядок основан на том, как файловая система работает внутри. Приложениям не следует ожидать, что они будут знать об этом, поэтому fs следует попытаться убедиться, что он перечисляет файлы в лучшем порядке для их чтения, что не всегда может быть порядком inode. – psusi 11 April 2014 в 18:48
  • 4
    @psusi, как fs должен обрабатывать случай, когда у вас есть два приложения, которым требуются файлы в другом порядке? Fs не может оптимизировать порядок физического хранения для обоих! Любое приложение, заинтересованное в производительности, должно запрашивать файлы в порядке хранения от fs. Если POSIX не разрешает такое упорядочение (отличное от порядка inode, которое может соответствовать или не соответствовать фактическому порядку физического хранения), это недостаток POSIX, а не fs. – Mikko Rantalainen 15 April 2014 в 10:43
  • 5
    @MikkoRantalainen, заказ не является требованием приложения, это требование файловой системы, следовательно, почему файловая система должна их заказывать, но это лучше всего. – psusi 15 April 2014 в 21:40

В итоге я написал небольшой скрипт python для вычисления корреляции между именами каталогов и inodes, inodes и блоками данных, а также именами каталогов для блоков данных. Оказывается, что ext4 имеет тенденцию иметь довольно плохую корреляцию между порядком, в котором имена файлов появляются в каталоге, и где они хранятся на диске. Обсудив его в списке рассылки ext4, выясняется, что это результат хешированных индексов каталога, используемых для ускорения поиска в больших каталогах. Имена хранятся в хэш-порядке, который эффективно скремблирует их порядок по отношению к чему-либо еще.

Мне кажется и, по крайней мере, еще одному комментатору, что это недостаток в fs, который должен быть исправлен. Тед Ц'о (сторонник экстренной службы) считает, что в fs будет слишком сложно сделать так, что хорошие инструменты (например, rsync и tar) должны иметь возможность сортировать каталог по номеру inode перед чтением файлов.

Таким образом, похоже, что запросы на повышение характеристик нужны для rsync и tar.

7
ответ дан 25 July 2018 в 22:22

В итоге я написал небольшой скрипт python для вычисления корреляции между именами каталогов и inodes, inodes и блоками данных, а также именами каталогов для блоков данных. Оказывается, что ext4 имеет тенденцию иметь довольно плохую корреляцию между порядком, в котором имена файлов появляются в каталоге, и где они хранятся на диске. Обсудив его в списке рассылки ext4, выясняется, что это результат хешированных индексов каталога, используемых для ускорения поиска в больших каталогах. Имена хранятся в хэш-порядке, который эффективно скремблирует их порядок по отношению к чему-либо еще.

Мне кажется и, по крайней мере, еще одному комментатору, что это недостаток в fs, который должен быть исправлен. Тед Ц'о (сторонник экстренной службы) считает, что в fs будет слишком сложно сделать так, что хорошие инструменты (например, rsync и tar) должны иметь возможность сортировать каталог по номеру inode перед чтением файлов.

Таким образом, похоже, что запросы на повышение характеристик нужны для rsync и tar.

7
ответ дан 2 August 2018 в 03:49

В итоге я написал небольшой скрипт python для вычисления корреляции между именами каталогов и inodes, inodes и блоками данных, а также именами каталогов для блоков данных. Оказывается, что ext4 имеет тенденцию иметь довольно плохую корреляцию между порядком, в котором имена файлов появляются в каталоге, и где они хранятся на диске. Обсудив его в списке рассылки ext4, выясняется, что это результат хешированных индексов каталога, используемых для ускорения поиска в больших каталогах. Имена хранятся в хэш-порядке, который эффективно скремблирует их порядок по отношению к чему-либо еще.

Мне кажется и, по крайней мере, еще одному комментатору, что это недостаток в fs, который должен быть исправлен. Тед Ц'о (сторонник экстренной службы) считает, что в fs будет слишком сложно сделать так, что хорошие инструменты (например, rsync и tar) должны иметь возможность сортировать каталог по номеру inode перед чтением файлов.

Таким образом, похоже, что запросы на повышение характеристик нужны для rsync и tar.

7
ответ дан 4 August 2018 в 19:53

В итоге я написал небольшой скрипт python для вычисления корреляции между именами каталогов и inodes, inodes и блоками данных, а также именами каталогов для блоков данных. Оказывается, что ext4 имеет тенденцию иметь довольно плохую корреляцию между порядком, в котором имена файлов появляются в каталоге, и где они хранятся на диске. Обсудив его в списке рассылки ext4, выясняется, что это результат хешированных индексов каталога, используемых для ускорения поиска в больших каталогах. Имена хранятся в хэш-порядке, который эффективно скремблирует их порядок по отношению к чему-либо еще.

Мне кажется и, по крайней мере, еще одному комментатору, что это недостаток в fs, который должен быть исправлен. Тед Ц'о (сторонник экстренной службы) считает, что в fs будет слишком сложно сделать так, что хорошие инструменты (например, rsync и tar) должны иметь возможность сортировать каталог по номеру inode перед чтением файлов.

Таким образом, похоже, что запросы на повышение характеристик нужны для rsync и tar.

7
ответ дан 6 August 2018 в 03:56

В итоге я написал небольшой скрипт python для вычисления корреляции между именами каталогов и inodes, inodes и блоками данных, а также именами каталогов для блоков данных. Оказывается, что ext4 имеет тенденцию иметь довольно плохую корреляцию между порядком, в котором имена файлов появляются в каталоге, и где они хранятся на диске. Обсудив его в списке рассылки ext4, выясняется, что это результат хешированных индексов каталога, используемых для ускорения поиска в больших каталогах. Имена хранятся в хэш-порядке, который эффективно скремблирует их порядок по отношению к чему-либо еще.

Мне кажется и, по крайней мере, еще одному комментатору, что это недостаток в fs, который должен быть исправлен. Тед Ц'о (сторонник экстренной службы) считает, что в fs будет слишком сложно сделать так, что хорошие инструменты (например, rsync и tar) должны иметь возможность сортировать каталог по номеру inode перед чтением файлов.

Таким образом, похоже, что запросы на повышение характеристик нужны для rsync и tar.

7
ответ дан 7 August 2018 в 21:53

Несколько точек для рассмотрения:

Сколько файлов мы говорим? find /path/to/your/maildir/ | wc -l должен дать вам приблизительное указание. Сотни тысяч должны быть в порядке. Сотни миллионов могут предложить вам обрезать, архивировать и вообще очищать. Является ли диск медленным? Существует множество эталонных тестов, таких как всеобъемлющий bonnie++, до простого и простого бенчмаркера Disk Utility. Запустите один и посмотрите, страдаете ли вы. Это может вызвать проблемы с оборудованием - замените что-то более быстрое. Проблемы с файловой системой. Используете ли вы что-то известное очень медленно при высоких случайных чтениях IOPS?

Но в конечном счете, кольцо tar, а затем передача должно дать вам наилучшую общую пропускную способность за счет того, что вы должны быть там, чтобы настроить передачу, как только вы создали tar.

2
ответ дан 25 May 2018 в 22:36
  • 1
    Может быть, сто тысяч файлов, но не миллионы. Диск на старой системе делает где-то около 50-60 мб / с, а новая система - raid5, которая составляет около 160. Оба они значительно превосходят 11 или около того мб / с, с которыми может справиться быстрый ethernet. Кажется, что проблема заключается в шаблоне произвольного доступа. – psusi 11 March 2011 в 05:36

Попробуйте отключить отслеживание atime или использовать относительное atime в новом разделе диска. Это ограничит накладные расходы. Изменение из файловой системы, не содержащей журналов, например ext2, в файловую систему журналов, например ext3 или ext4, будет иметь некоторые образы производительности

Когда я переместил Maildirs, я сделал подготовительный rsync, чтобы получить все каталоги на месте впереди время.

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

поместите SMTP-демона в режим только очереди , отключить запуск очереди с помощью SMTP-демона и отключить доступ пользователя.

Повторно активизируется после завершения перемещения файла.

EDIT: Я думаю, вы определили проблему. Tar и rsync будут ходить по каталогам. Из-за обычных изменений файла в Maildir файлы для каждого каталога будут разбросаны по всему диску. Инструмент, подобный дампу, будет читать раздел в блочном порядке, но реплицирует проблему на новый раздел. Второй rsync должен работать намного быстрее, чем второй.

1
ответ дан 25 May 2018 в 22:36
  • 1
    Тар обходит обновления атима, и я думаю, что rsync тоже. Это с ext4. – psusi 11 March 2011 в 18:29
  • 2
    @psusi: изменение Atime является общим исправлением для сильно читаемых разделов. С другой стороны, это не поможет писать файлы из tar или rsync. Каталоги все равно будут записаны. – BillThor 11 March 2011 в 18:50
  • 3
    Дамп не реплицирует проблему на новый раздел. В то время как дамп считывает необработанное блочное устройство, восстановление не записывается на необработанное блочное устройство; он проходит через обычный файл IO. Также я считаю, что дамп читается в порядке inode. Именно поэтому на новом диске было так быстро, так как существует очень сильная корреляция между индексом и блочным порядком, но на старом диске эта корреляция была не такой сильной, но лучше, чем корреляция между именами файлов и блоками, что почему он сделал намного лучше, чем смола. – psusi 11 March 2011 в 19:57
  • 4
    @psusi: он может сжимать любое свободное пространство, но inodes в более раннем каталоге Maildir будут относительно случайными, так как это будет блокировать расположение файлов. Файлы могут перемещаться, но случайность местоположения, вероятно, останется. Это может быть несколько лучше, но может быть хуже. rsync и tar должны сделать иноды и распределение пространства относительно последовательными, особенно на новом разделе. Второй rsync, который я предложил, начнет процесс рандомизации. – BillThor 11 March 2011 в 20:03
  • 5
    @BillThor да, получат ли они новый раздел через rsync, tar или дамп, они обычно начинаются в довольно хорошем порядке. Вопрос в том, как исправить старый Maildir, чтобы чтение его с помощью tar или rsync было не так медленным? Или, может быть, исправить tar и rsync, чтобы они читали в более оптимальном порядке. – psusi 11 March 2011 в 21:06

Попробуйте отключить отслеживание atime или использовать относительное atime в новом разделе диска. Это ограничит накладные расходы. Изменение из файловой системы, не содержащей журналов, например ext2, в файловую систему журналов, например ext3 или ext4, будет иметь некоторые образы производительности

Когда я переместил Maildirs, я сделал подготовительный rsync, чтобы получить все каталоги на месте впереди время.

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

поместите SMTP-демона в режим только очереди , отключить запуск очереди с помощью SMTP-демона и отключить доступ пользователя.

Повторно активизируется после завершения перемещения файла.

EDIT: Я думаю, вы определили проблему. Tar и rsync будут ходить по каталогам. Из-за обычных изменений файла в Maildir файлы для каждого каталога будут разбросаны по всему диску. Инструмент, подобный дампу, будет читать раздел в блочном порядке, но реплицирует проблему на новый раздел. Второй rsync должен работать намного быстрее, чем второй.

1
ответ дан 25 July 2018 в 22:22
  • 1
    Тар обходит обновления атима, и я думаю, что rsync тоже. Это с ext4. – psusi 11 March 2011 в 18:29
  • 2
    @psusi: изменение Atime является общим исправлением для сильно читаемых разделов. С другой стороны, это не поможет писать файлы из tar или rsync. Каталоги все равно будут записаны. – BillThor 11 March 2011 в 18:50
  • 3
    Дамп не реплицирует проблему на новый раздел. В то время как дамп считывает необработанное блочное устройство, восстановление не записывается на необработанное блочное устройство; он проходит через обычный файл IO. Также я считаю, что дамп читается в порядке inode. Именно поэтому на новом диске было так быстро, так как существует очень сильная корреляция между индексом и блочным порядком, но на старом диске эта корреляция была не такой сильной, но лучше, чем корреляция между именами файлов и блоками, что почему он сделал намного лучше, чем смола. – psusi 11 March 2011 в 19:57
  • 4
    @psusi: он может сжимать любое свободное пространство, но inodes в более раннем каталоге Maildir будут относительно случайными, так как это будет блокировать расположение файлов. Файлы могут перемещаться, но случайность местоположения, вероятно, останется. Это может быть несколько лучше, но может быть хуже. rsync и tar должны сделать иноды и распределение пространства относительно последовательными, особенно на новом разделе. Второй rsync, который я предложил, начнет процесс рандомизации. – BillThor 11 March 2011 в 20:03
  • 5
    @BillThor да, получат ли они новый раздел через rsync, tar или дамп, они обычно начинаются в довольно хорошем порядке. Вопрос в том, как исправить старый Maildir, чтобы чтение его с помощью tar или rsync было не так медленным? Или, может быть, исправить tar и rsync, чтобы они читали в более оптимальном порядке. – psusi 11 March 2011 в 21:06

Несколько точек для рассмотрения:

Сколько файлов мы говорим? find /path/to/your/maildir/ | wc -l должен дать вам приблизительное указание. Сотни тысяч должны быть в порядке. Сотни миллионов могут предложить вам обрезать, архивировать и вообще очищать. Является ли диск медленным? Существует множество эталонных тестов, таких как всеобъемлющий bonnie++, до простого и простого бенчмаркера Disk Utility. Запустите один и посмотрите, страдаете ли вы. Это может вызвать проблемы с оборудованием - замените что-то более быстрое. Проблемы с файловой системой. Используете ли вы что-то известное очень медленно при высоких случайных чтениях IOPS?

Но в конечном счете, кольцо tar, а затем передача должно дать вам наилучшую общую пропускную способность за счет того, что вы должны быть там, чтобы настроить передачу, как только вы создали tar.

2
ответ дан 25 July 2018 в 22:22
  • 1
    Может быть, сто тысяч файлов, но не миллионы. Диск на старой системе делает где-то около 50-60 мб / с, а новая система - raid5, которая составляет около 160. Оба они значительно превосходят 11 или около того мб / с, с которыми может справиться быстрый ethernet. Кажется, что проблема заключается в шаблоне произвольного доступа. – psusi 11 March 2011 в 05:36

Попробуйте отключить отслеживание atime или использовать относительное atime в новом разделе диска. Это ограничит накладные расходы. Изменение из файловой системы, не содержащей журналов, например ext2, в файловую систему журналов, например ext3 или ext4, будет иметь некоторые образы производительности

Когда я переместил Maildirs, я сделал подготовительный rsync, чтобы получить все каталоги на месте впереди время.

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

поместите SMTP-демона в режим только очереди , отключить запуск очереди с помощью SMTP-демона и отключить доступ пользователя.

Повторно активизируется после завершения перемещения файла.

EDIT: Я думаю, вы определили проблему. Tar и rsync будут ходить по каталогам. Из-за обычных изменений файла в Maildir файлы для каждого каталога будут разбросаны по всему диску. Инструмент, подобный дампу, будет читать раздел в блочном порядке, но реплицирует проблему на новый раздел. Второй rsync должен работать намного быстрее, чем второй.

1
ответ дан 2 August 2018 в 03:49
  • 1
    Тар обходит обновления атима, и я думаю, что rsync тоже. Это с ext4. – psusi 11 March 2011 в 18:29
  • 2
    @psusi: изменение Atime является общим исправлением для сильно читаемых разделов. С другой стороны, это не поможет писать файлы из tar или rsync. Каталоги все равно будут записаны. – BillThor 11 March 2011 в 18:50
  • 3
    Дамп не реплицирует проблему на новый раздел. В то время как дамп считывает необработанное блочное устройство, восстановление не записывается на необработанное блочное устройство; он проходит через обычный файл IO. Также я считаю, что дамп читается в порядке inode. Именно поэтому на новом диске было так быстро, так как существует очень сильная корреляция между индексом и блочным порядком, но на старом диске эта корреляция была не такой сильной, но лучше, чем корреляция между именами файлов и блоками, что почему он сделал намного лучше, чем смола. – psusi 11 March 2011 в 19:57
  • 4
    @psusi: он может сжимать любое свободное пространство, но inodes в более раннем каталоге Maildir будут относительно случайными, так как это будет блокировать расположение файлов. Файлы могут перемещаться, но случайность местоположения, вероятно, останется. Это может быть несколько лучше, но может быть хуже. rsync и tar должны сделать иноды и распределение пространства относительно последовательными, особенно на новом разделе. Второй rsync, который я предложил, начнет процесс рандомизации. – BillThor 11 March 2011 в 20:03
  • 5
    @BillThor да, получат ли они новый раздел через rsync, tar или дамп, они обычно начинаются в довольно хорошем порядке. Вопрос в том, как исправить старый Maildir, чтобы чтение его с помощью tar или rsync было не так медленным? Или, может быть, исправить tar и rsync, чтобы они читали в более оптимальном порядке. – psusi 11 March 2011 в 21:06

Несколько точек для рассмотрения:

Сколько файлов мы говорим? find /path/to/your/maildir/ | wc -l должен дать вам приблизительное указание. Сотни тысяч должны быть в порядке. Сотни миллионов могут предложить вам обрезать, архивировать и вообще очищать. Является ли диск медленным? Существует множество эталонных тестов, таких как всеобъемлющий bonnie++, до простого и простого бенчмаркера Disk Utility. Запустите один и посмотрите, страдаете ли вы. Это может вызвать проблемы с оборудованием - замените что-то более быстрое. Проблемы с файловой системой. Используете ли вы что-то известное очень медленно при высоких случайных чтениях IOPS?

Но в конечном счете, кольцо tar, а затем передача должно дать вам наилучшую общую пропускную способность за счет того, что вы должны быть там, чтобы настроить передачу, как только вы создали tar.

2
ответ дан 2 August 2018 в 03:49
  • 1
    Может быть, сто тысяч файлов, но не миллионы. Диск на старой системе делает где-то около 50-60 мб / с, а новая система - raid5, которая составляет около 160. Оба они значительно превосходят 11 или около того мб / с, с которыми может справиться быстрый ethernet. Кажется, что проблема заключается в шаблоне произвольного доступа. – psusi 11 March 2011 в 05:36

Попробуйте отключить отслеживание atime или использовать относительное atime в новом разделе диска. Это ограничит накладные расходы. Изменение из файловой системы, не содержащей журналов, например ext2, в файловую систему журналов, например ext3 или ext4, будет иметь некоторые образы производительности

Когда я переместил Maildirs, я сделал подготовительный rsync, чтобы получить все каталоги на месте впереди время.

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

поместите SMTP-демона в режим только очереди , отключить запуск очереди с помощью SMTP-демона и отключить доступ пользователя.

Повторно активизируется после завершения перемещения файла.

EDIT: Я думаю, вы определили проблему. Tar и rsync будут ходить по каталогам. Из-за обычных изменений файла в Maildir файлы для каждого каталога будут разбросаны по всему диску. Инструмент, подобный дампу, будет читать раздел в блочном порядке, но реплицирует проблему на новый раздел. Второй rsync должен работать намного быстрее, чем второй.

1
ответ дан 4 August 2018 в 19:53
  • 1
    Тар обходит обновления атима, и я думаю, что rsync тоже. Это с ext4. – psusi 11 March 2011 в 18:29
  • 2
    @psusi: изменение Atime является общим исправлением для сильно читаемых разделов. С другой стороны, это не поможет писать файлы из tar или rsync. Каталоги все равно будут записаны. – BillThor 11 March 2011 в 18:50
  • 3
    Дамп не реплицирует проблему на новый раздел. В то время как дамп считывает необработанное блочное устройство, восстановление не записывается на необработанное блочное устройство; он проходит через обычный файл IO. Также я считаю, что дамп читается в порядке inode. Именно поэтому на новом диске было так быстро, так как существует очень сильная корреляция между индексом и блочным порядком, но на старом диске эта корреляция была не такой сильной, но лучше, чем корреляция между именами файлов и блоками, что почему он сделал намного лучше, чем смола. – psusi 11 March 2011 в 19:57
  • 4
    @psusi: он может сжимать любое свободное пространство, но inodes в более раннем каталоге Maildir будут относительно случайными, так как это будет блокировать расположение файлов. Файлы могут перемещаться, но случайность местоположения, вероятно, останется. Это может быть несколько лучше, но может быть хуже. rsync и tar должны сделать иноды и распределение пространства относительно последовательными, особенно на новом разделе. Второй rsync, который я предложил, начнет процесс рандомизации. – BillThor 11 March 2011 в 20:03
  • 5
    @BillThor да, получат ли они новый раздел через rsync, tar или дамп, они обычно начинаются в довольно хорошем порядке. Вопрос в том, как исправить старый Maildir, чтобы чтение его с помощью tar или rsync было не так медленным? Или, может быть, исправить tar и rsync, чтобы они читали в более оптимальном порядке. – psusi 11 March 2011 в 21:06

Несколько точек для рассмотрения:

Сколько файлов мы говорим? find /path/to/your/maildir/ | wc -l должен дать вам приблизительное указание. Сотни тысяч должны быть в порядке. Сотни миллионов могут предложить вам обрезать, архивировать и вообще очищать. Является ли диск медленным? Существует множество эталонных тестов, таких как всеобъемлющий bonnie++, до простого и простого бенчмаркера Disk Utility. Запустите один и посмотрите, страдаете ли вы. Это может вызвать проблемы с оборудованием - замените что-то более быстрое. Проблемы с файловой системой. Используете ли вы что-то известное очень медленно при высоких случайных чтениях IOPS?

Но в конечном счете, кольцо tar, а затем передача должно дать вам наилучшую общую пропускную способность за счет того, что вы должны быть там, чтобы настроить передачу, как только вы создали tar.

2
ответ дан 4 August 2018 в 19:53
  • 1
    Может быть, сто тысяч файлов, но не миллионы. Диск на старой системе делает где-то около 50-60 мб / с, а новая система - raid5, которая составляет около 160. Оба они значительно превосходят 11 или около того мб / с, с которыми может справиться быстрый ethernet. Кажется, что проблема заключается в шаблоне произвольного доступа. – psusi 11 March 2011 в 05:36

Попробуйте отключить отслеживание atime или использовать относительное atime в новом разделе диска. Это ограничит накладные расходы. Изменение из файловой системы, не содержащей журналов, например ext2, в файловую систему журналов, например ext3 или ext4, будет иметь некоторые образы производительности

Когда я переместил Maildirs, я сделал подготовительный rsync, чтобы получить все каталоги на месте впереди время.

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

поместите SMTP-демона в режим только очереди , отключить запуск очереди с помощью SMTP-демона и отключить доступ пользователя.

Повторно активизируется после завершения перемещения файла.

EDIT: Я думаю, вы определили проблему. Tar и rsync будут ходить по каталогам. Из-за обычных изменений файла в Maildir файлы для каждого каталога будут разбросаны по всему диску. Инструмент, подобный дампу, будет читать раздел в блочном порядке, но реплицирует проблему на новый раздел. Второй rsync должен работать намного быстрее, чем второй.

1
ответ дан 6 August 2018 в 03:56
  • 1
    Тар обходит обновления атима, и я думаю, что rsync тоже. Это с ext4. – psusi 11 March 2011 в 18:29
  • 2
    @psusi: изменение Atime является общим исправлением для сильно читаемых разделов. С другой стороны, это не поможет писать файлы из tar или rsync. Каталоги все равно будут записаны. – BillThor 11 March 2011 в 18:50
  • 3
    Дамп не реплицирует проблему на новый раздел. В то время как дамп считывает необработанное блочное устройство, восстановление не записывается на необработанное блочное устройство; он проходит через обычный файл IO. Также я считаю, что дамп читается в порядке inode. Именно поэтому на новом диске было так быстро, так как существует очень сильная корреляция между индексом и блочным порядком, но на старом диске эта корреляция была не такой сильной, но лучше, чем корреляция между именами файлов и блоками, что почему он сделал намного лучше, чем смола. – psusi 11 March 2011 в 19:57
  • 4
    @psusi: он может сжимать любое свободное пространство, но inodes в более раннем каталоге Maildir будут относительно случайными, так как это будет блокировать расположение файлов. Файлы могут перемещаться, но случайность местоположения, вероятно, останется. Это может быть несколько лучше, но может быть хуже. rsync и tar должны сделать иноды и распределение пространства относительно последовательными, особенно на новом разделе. Второй rsync, который я предложил, начнет процесс рандомизации. – BillThor 11 March 2011 в 20:03
  • 5
    @BillThor да, получат ли они новый раздел через rsync, tar или дамп, они обычно начинаются в довольно хорошем порядке. Вопрос в том, как исправить старый Maildir, чтобы чтение его с помощью tar или rsync было не так медленным? Или, может быть, исправить tar и rsync, чтобы они читали в более оптимальном порядке. – psusi 11 March 2011 в 21:06

Несколько точек для рассмотрения:

Сколько файлов мы говорим? find /path/to/your/maildir/ | wc -l должен дать вам приблизительное указание. Сотни тысяч должны быть в порядке. Сотни миллионов могут предложить вам обрезать, архивировать и вообще очищать. Является ли диск медленным? Существует множество эталонных тестов, таких как всеобъемлющий bonnie++, до простого и простого бенчмаркера Disk Utility. Запустите один и посмотрите, страдаете ли вы. Это может вызвать проблемы с оборудованием - замените что-то более быстрое. Проблемы с файловой системой. Используете ли вы что-то известное очень медленно при высоких случайных чтениях IOPS?

Но в конечном счете, кольцо tar, а затем передача должно дать вам наилучшую общую пропускную способность за счет того, что вы должны быть там, чтобы настроить передачу, как только вы создали tar.

2
ответ дан 6 August 2018 в 03:56
  • 1
    Может быть, сто тысяч файлов, но не миллионы. Диск на старой системе делает где-то около 50-60 мб / с, а новая система - raid5, которая составляет около 160. Оба они значительно превосходят 11 или около того мб / с, с которыми может справиться быстрый ethernet. Кажется, что проблема заключается в шаблоне произвольного доступа. – psusi 11 March 2011 в 05:36

Попробуйте отключить отслеживание atime или использовать относительное atime в новом разделе диска. Это ограничит накладные расходы. Изменение из файловой системы, не содержащей журналов, например ext2, в файловую систему журналов, например ext3 или ext4, будет иметь некоторые образы производительности

Когда я переместил Maildirs, я сделал подготовительный rsync, чтобы получить все каталоги на месте впереди время.

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

поместите SMTP-демона в режим только очереди , отключить запуск очереди с помощью SMTP-демона и отключить доступ пользователя.

Повторно активизируется после завершения перемещения файла.

EDIT: Я думаю, вы определили проблему. Tar и rsync будут ходить по каталогам. Из-за обычных изменений файла в Maildir файлы для каждого каталога будут разбросаны по всему диску. Инструмент, подобный дампу, будет читать раздел в блочном порядке, но реплицирует проблему на новый раздел. Второй rsync должен работать намного быстрее, чем второй.

1
ответ дан 7 August 2018 в 21:53
  • 1
    Тар обходит обновления атима, и я думаю, что rsync тоже. Это с ext4. – psusi 11 March 2011 в 18:29
  • 2
    @psusi: изменение Atime является общим исправлением для сильно читаемых разделов. С другой стороны, это не поможет писать файлы из tar или rsync. Каталоги все равно будут записаны. – BillThor 11 March 2011 в 18:50
  • 3
    Дамп не реплицирует проблему на новый раздел. В то время как дамп считывает необработанное блочное устройство, восстановление не записывается на необработанное блочное устройство; он проходит через обычный файл IO. Также я считаю, что дамп читается в порядке inode. Именно поэтому на новом диске было так быстро, так как существует очень сильная корреляция между индексом и блочным порядком, но на старом диске эта корреляция была не такой сильной, но лучше, чем корреляция между именами файлов и блоками, что почему он сделал намного лучше, чем смола. – psusi 11 March 2011 в 19:57
  • 4
    @psusi: он может сжимать любое свободное пространство, но inodes в более раннем каталоге Maildir будут относительно случайными, так как это будет блокировать расположение файлов. Файлы могут перемещаться, но случайность местоположения, вероятно, останется. Это может быть несколько лучше, но может быть хуже. rsync и tar должны сделать иноды и распределение пространства относительно последовательными, особенно на новом разделе. Второй rsync, который я предложил, начнет процесс рандомизации. – BillThor 11 March 2011 в 20:03
  • 5
    @BillThor да, получат ли они новый раздел через rsync, tar или дамп, они обычно начинаются в довольно хорошем порядке. Вопрос в том, как исправить старый Maildir, чтобы чтение его с помощью tar или rsync было не так медленным? Или, может быть, исправить tar и rsync, чтобы они читали в более оптимальном порядке. – psusi 11 March 2011 в 21:06

Несколько точек для рассмотрения:

Сколько файлов мы говорим? find /path/to/your/maildir/ | wc -l должен дать вам приблизительное указание. Сотни тысяч должны быть в порядке. Сотни миллионов могут предложить вам обрезать, архивировать и вообще очищать. Является ли диск медленным? Существует множество эталонных тестов, таких как всеобъемлющий bonnie++, до простого и простого бенчмаркера Disk Utility. Запустите один и посмотрите, страдаете ли вы. Это может вызвать проблемы с оборудованием - замените что-то более быстрое. Проблемы с файловой системой. Используете ли вы что-то известное очень медленно при высоких случайных чтениях IOPS?

Но в конечном счете, кольцо tar, а затем передача должно дать вам наилучшую общую пропускную способность за счет того, что вы должны быть там, чтобы настроить передачу, как только вы создали tar.

2
ответ дан 7 August 2018 в 21:53
  • 1
    Может быть, сто тысяч файлов, но не миллионы. Диск на старой системе делает где-то около 50-60 мб / с, а новая система - raid5, которая составляет около 160. Оба они значительно превосходят 11 или около того мб / с, с которыми может справиться быстрый ethernet. Кажется, что проблема заключается в шаблоне произвольного доступа. – psusi 11 March 2011 в 05:36

Другие вопросы по тегам:

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