История изменений

Хм, тут есть несколько моментов:

1. У 860 EVO на 500ГБ, на полной скорости, можно записать около 25ГБ, потом следет просадка до ~300МБ/с. Пруфы, картинка взята отсюда

2. Если я правильно понял, данные для индексации хранятся в zip архивах. Я не знаю как xapian индексирует zip файлы. Но если он их распаковывает, то хорошо бы понять куда именно. И по возможности перенести это место в оперативку — tmpfs или zram (на всякий случай уточню, что zram это прежде всего сжатое блочное устройство в оперативке и совсем не обязательно swap). Собственно, если tmpfs есть, то можно дать ему больше оперативки

3. Если верить документации, то Xapian пишет изменения на диск атамарно и гарантирует целостность данных при условии, что диски/RAID гарантируют, что данные отданые им в direct режиме будут записаны. Такое поведение, конечно же сильно уменьшает скорость записи на диск. И его можно отключить. Из документации:

Finally, note that it is possible to compile Xapian such that it doesn’t make modifications in an atomic manner, in order to build very large databases more quickly (search the Xapian mailing list archives for “DANGEROUS” mode for more details). This isn’t yet integrated into standard builds of Xapian, but may be in future, if appropriate protections can be incorporated.

4. Если пункт 3 будет выполнен, то можно попытаться оптимизировать запись на диск — увеличить dirty_ratio с дефолтных 20% до 70-80%, что позволит держать в оперативной памяти больше данных.

5. Дополнительно, можно попробовать увеличить очередь чтения/ записи на диск (сработает, вероятно, и без пункта 3). Не факт, что станет лучше, но можно проверить
Сначала отключаем mq-blk — ставим параметр загрузки
scsi_mod.use_blk_mq=0
Затем в уже перезагруженой системе выставляем очередь и шедулер
echo 10000 > /sys/block/sda/queue/nr_requests
echo deadline > /sys/block/sda/queue/scheduler
где sda — SSD. Значение в 10000, обычно, более чем достаточно.

Хм, тут есть несколько моментов:

1. У 860 EVO на 500ГБ, на полной скорости, можно записать около 25ГБ, потом следет просадка до ~300МБ/с. Пруфы, картинка взята отсюда

2. Если я правильно понял, данные для индексации хранятся в zip архивах. Я не знаю как xapian индексирует zip файлы. Но если он их распаковывает, то хорошо бы понять куда именно. И по возможности перенести это место в оперативку — tmpfs или zram (на всякий случай уточню, что zram это прежде всего сжатое блочное устройство в оперативке и совсем не обязательно swap). Собственно, если tmpfs есть, то можно дать ему больше оперативки

3. Если верить документации, то Xapian пишет изменения на диск атамарно и гарантирует целостность данных при условии, что диски/RAID гарантируют, что данные отданые им в direct режиме будут записаны. Такое поведение, конечно же сильно уменьшает скорость записи на диск. И его можно отключить. Из документации:

Finally, note that it is possible to compile Xapian such that it doesn’t make modifications in an atomic manner, in order to build very large databases more quickly (search the Xapian mailing list archives for “DANGEROUS” mode for more details). This isn’t yet integrated into standard builds of Xapian, but may be in future, if appropriate protections can be incorporated.

4. Если пункт 3 будет выполнен, то можно попытаться оптимизировать запись на диск — увеличить dirty_ratio с дефолтных 20% до 70-80%, что позволит держать в оперативной памяти больше данных.

5. Дополнительно, можно попробовать увеличить очередь чтения/ записи на диск (сработает, вероятно, и без пункта 3). Не факт, что станет лучше, но можно проверить
Сначала отключаем mq-blk — ставим параметр загрузки
scsi_mod.use_blk_mq=0
Затем в уже перезагруженой системе выставляем очередь и шедулер echo 10000 > /sys/block/sda/queue/nr_requests
echo deadline > /sys/block/sda/queue/scheduler где sda — SSD. Значение в 10000, обычно, более чем достаточно.