Когда размер журнала больше, производительность низкая

Question

У меня есть несколько процессов, работающих во встроенной системе под управлением Linux. Каждый процесс сбрасывает свои журналы в соответствующие файлы журнала, После того, как файлы журналов достигнут 20 МБ, журналы будут перезаписаны сверху донизу.

Пример:

Если предположим, что, мой журнал имеет предел 10 линии, после написания 10-й линии, он будет вернуться к 1-й строке и начать писать на 1-й линии, 2-й линии и так далее.

Но проблема в том, что размер журнала меньше, скажем, 5 МБ, скорость лучше. Если размер журнала составляет 20 МБ, он становится медленнее, чем больше размер файла, тем медленнее система.

Не могли бы вы объяснить причину этого?

Answer 1

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

Лучшая концепция: Журнал вращения. Вместо того, чтобы иметь один файл размером 20 Мбайт, сохраните два файла размером 10 МБ. После того, как первый достигнет предела, вы переместите его во второй файл (таким образом отбросив второй файл) и снова запустите первый файл. Тогда вам не придется переписывать ваши файлы. Вместо этого вы всегда только добавляете в текущий журнал, который обычно очень быстрый.

Answer 2

Я думаю, что есть две основные причины. пункт 1) Программного обеспечения зрения (Linux Kernel) 2) Оборудование точка зрения (Жесткий диск предполагается)

точки зрения программного обеспечения: Это зависит от типа файловой системы в использовании, а также насколько эффективно файловая система управляет диском пространство. В Linux есть что-то, называемое «буферным кешем», которое используется всеми файловыми системами, и каждая запись в любой из ваших файлов сначала переходит в буферный кеш, и это мгновенно очищается демонами ядра. Существует некоторый верхний предел количества записываемых буферных блоков в кеше, как только он достигнет предела, он будет сбрасывать их на соответствующие драйверы, которые запустится на диск.

Как и в вашем случае, если, например, вы пишете около 100 байт данных и при достижении определенного предела, вернитесь к началу файла и продолжите это. В этом случае количество записываемых блоков буфера, которые вы генерируете в течение определенного периода времени в файле размером 20 МБ, больше по сравнению с 5 МБ. И другим важным моментом является то, что число чтения/записи на диске больше в случае файла с 20 МБ, потому что ядро ​​очищает больше от большего файла, так как может иметь более грязные блоки. Но в файле размером 5 МБ грязные блоки, хотя и не так много, вы все равно можете перезаписать их до того, как ядро ​​выведет их на диск.

Аппаратная точка зрения: Это зависит от количества движений спинов и барабанов, которые должны иметь место для чтения/записи вашего файла на диск. Предполагая, что ваше linux-ядро (драйвер файловой системы) пытается выделить секвенсорные секторы на жестком диске, возможно, что файл размером 20 МБ занимает сектора, которые разбросаны по всему диску, в то время как 5 МБ очень мало разбросано esp с сильно используемым жестким диском. Это означает, что если ваш файл равен 100 МБ, он будет медленнее по сравнению с файлом 20 МБ.И поскольку вы будете многократно переписываться в секторы, которые вы уже написали, вращение руки будет больше в случае 20 МБ файла по сравнению с файлом 5 МБ, особенно если доступ к диску больше в случае с 20 МБ.

Это то, что я думаю, что файл будет читать/записывать медленнее по мере увеличения размера файла. И снова, в приведенном выше объяснении, я не рассмотрел несколько процессов, записывающих несколько файлов. Это сделает чтение/запись еще медленнее на HDD ..