![эффективные обновления файлов под Linux](https://rvso.com/image/567645/%D1%8D%D1%84%D1%84%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5%20%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F%20%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%20%D0%BF%D0%BE%D0%B4%20Linux.png)
Какой метод обновления файла размером 30 КБ на диске является наиболее эффективным в условиях высокой производительности (множество одновременных обновлений) в Linux:
1. просто обновите соответствующий файл
2. удалите старый файл и сохраните новый
Меня больше всего беспокоит время доступа к диску, но здесь также может иметь значение загрузка процессора.
решение1
Подсистема диска и файловая система, которые вы используете, будут иметь здесь огромное влияние. Фактически, существует так много различных возможных результатов, что вам, вероятно, следует провести бенчмаркинг. Однако:
- помните, что реальные синхронные операции ввода-вывода ограничены примерно 100 IOPS для диска SATA, 200 для диска SAS и сильно варьируются от 10 IOPS до 10000 для SSD. Умножьте количество IOPS на количество дисков с данными.
- Современные файловые системы будут группировать операции записи вместе. Правильный выбор файловой системы и детальная настройка изменят результаты в 10-100 раз.
- Современные контроллеры хранения могут кэшировать записи. Правильные настройки кэша обратной записи снова изменят результаты в 10–1000 раз.
Поэтому правильное оборудование (настоящий RAID-контроллер с кэшем WB, SSD), правильное программное обеспечение (современная файловая система, ext3 здесь совершенно не рассматривается, я бы выбрал xfs, но ext4 тоже вариант) и правильная настройка (тестирование различных планировщиков ввода-вывода ядра, размера ввода-вывода и т. д.) окажут огромное влияние.
решение2
Если вы его МНОГО обновляете, то устаревание содержимого файлов вряд ли будет для вас проблемой. Если так, поместите его в tmpfs, обрежьте файл при обновлении и перезапишите в него. Это будет самый дешевый метод, так как он, скорее всего, вообще не будет использовать диск.
Следующим наиболее близким вариантом является усечение/запись в файловую систему, которая имеетнет времениопция монтирования установлена, а журналирование отключено. Но опять же, это рискованно, если вы выйдете из строя, так как вы можете потерять данные.
После этого снова нет времени на ведение дневника.
Помните, что Linux буферизует записи и синхронизирует их с диском с определенными интервалами, поэтому вы обычно не «почувствуете» влияние записи с точки зрения ввода-вывода (если только это не очень тяжелая запись, но это настраивается). Вы также можете изменить условия синхронизации с диском, чтобы буфер записи заполнялся довольно долго перед синхронизацией с диском.
Если вы после того, как сделаете что-то действительно умное... используйте fallocate для предварительного выделения места для файла, что будет его максимально возможным значением. Затем mmap открывает файл, чтобы прочитать его напрямую в память. Тогда перезапись будет почти мгновенной (но с потерями, если у вас отключилось питание). Затем вы можете контролировать, когда сбрасывать обратно на диск с помощью вызова msync.
решение3
Если предположить, что это ПЛОСКИЙ файл, а не файл базы данных, то на самом деле плюсы и минусы каждого из методов:
Если вы просто перезапишете содержимое файла на месте, то вы, безусловно, предотвратите шаги перераспределения. Так что вы можете сэкономить немного времени. Однако размещение частей может быть неоптимальным.
Вы можете получить более оптимальное размещение данных в зависимости от фрагментации диска. Но это будет немного медленнее, так как пространство должно быть выделено, и если вы работаете в более безопасной среде, потребуется время на обнуление блока перед выделением.