Запись логов в файл. Последствия для памяти

Вечер добрый!
У меня давно есть некий код, который я использую для логгирования своих приложений. Суть его в том, что при инициализации логгера задается максимальное количество строк для файла и приложение передает в него по одной строке, которая добавляется в конец файла. Каждый раз при добавлении проверяется, превысили ли мы максимально допустимое количество строк и если да, то логгер удаляет самую верхнюю строку текстового файла и т.д.
При добавлении каждой строки происходит процедура открытия и закрытия файла.
Подскажите пожалуйста, есть ли принципиальная разница в том, оставлять файл открытым или открывать и закрывать его при каждом добавлении сроки?
Интересуют нюансы работы с памятью, в частности, не происходит ли при открытии и закрытии записи какой-то инфы в файл, что при частых манипуляциях может затирать досмерти ячейки памяти и т.п.
Всем спасибо за участие!

0

Rius,

Про Wear Leveling

Спасибо за это. В целом технологию знаю, но на Хабре нашел статью, где четко написано, что минимальный размер записи это размер страницы у ssd, которая обычно 4киб. То бишь, минимальный размер в моем случае, должен быть один кластер

0

Вставлю свои 5 копеек.

Сообщение от a13428711 То бишь, минимальный размер в моем случае, должен быть один кластер

Даже если данных меньше, но выполняется их запись, то всё равно будет использован весь кластер.
a13428711, не заморачивайтесь такой ерундой как подгонка данных под размер кластера. Сегодня накопитель один, завтра другой. Вы пишите код на языке высокого уровня, вот и мыслите высокоуровнево, прислушивайтесь к советам по организации самого логирования, а оптимизацией пускай занимается контроллер накопителя.

1

Сообщение от a13428711 Но как именно происходит добавление?

Сообщение от Wolfdp берется крайний кластер отвечающий за конец файла, в него дозаписывается сколько влезет, а дальше идет выделение новых кластеров (у нас же вроде обсуждается добавление в конец файла).

На пальцах:
- кластер 4КБ.
- файл 6КБ, физически он на диске занимает 8КБ (это даже в свойствах файла можно глянуть)
- дозаписываете 8КБ. Первые 4КБ файла никто не трогает. Следующий кластер имеет свободных 2КБ. Допустим дозаписывает в этот же кластер (прям физически, но может и выделить новый). Нам нужно ещё записить 6КБ
- выделяем ещё два кластера. Один заполняется полностью, второй также -- только 2КБ. Теперь у нас новый конечный кластер заполненый наполовину. Файл весом 14КБ на диске теперь занимает 16КБ.

Сообщение от Uswer Вы пишите код на языке высокого уровня, вот и мыслите высокоуровнево

+1. Я выше писал что C# с файлом работает через десяток посредников, что сводит на нет любые ваши потуги в низкоуровневую оптимизацию.

Сообщение от a13428711 опрос возник глядя на БД, в которых данные могут добавляться сотни раз в секунду, при этом они не висят в оперативной памяти ожидая сохранения, а пишутся сразу на диск

Вы на 100% уверены в этом?
1. В БД есть log-файл, который отвечает за изменения данных. Грубо говоря выполнили 100500 раз UPDATE который ни на бит не поменял размер логически, но вот фактически файл БД выросли на 10ГБ. Т.е. записуються изменения рядом, т.к. это в сотню раз быстрее, чем править случайное место в файлах.
2. некоторый таблицы намерено выносят в ОЗУ.

0

Сообщение от wizard41 это к порядку считывания. Как вы системе даете понять, что считывать надо с ЭТОГО места и до ЭТОГО, причем учитывая кодировки и прочую лабуду... ? Как СИСТЕМА вставит в конец файла часть, не изучив перед этим где этот КОНЕЦ и как его интерпретировать?

файловая система имеет таблицу кластеров, то есть по сути у вас файл соотносится с размером кластера, а кластер файловой системы занимает несколько секторов диска. Поэтому если вы пишете файлы не превышая размер кластера, например у вас 16 Кб кластер, то у вас на низком уровне будет считываться 32 сектора (если у вас HDD/SSD состоит из секторов по 512 байт). Всё это в ОЗУ и этим занимается сама ОС, для вас, на высоком уровне всё это незаметно. Если вы например в эти 16 Кб сохранили файл размером в 10 Кб, то у вас будет файл в 10 Кб, хранящийся в кластере в 16 Кб и занимающий на диске 32 сектора. Когда вы дописываете что-то, ОС прочитает кластер целиком (а скорее всего несколько кластеров, которые будут кешированы) в ОЗУ, допишет например еще 2 Кб и сохранит кластер целиком. Байты писать на диск никто не будет, для ОС кластер и будет минимальным контейнером. Если вы превысили размер кластера - ОС вам выделит еще один кластер.
Функция Seek() даст команду по положению в байтах и сама ОС определит какие кластеры нужно считать/дописать/переписать. Очевидно что тут всё упрётся в оптимизации самой ОС и драйвера файловой системы, как там они конкретно Seek() обработают, но не думаю что алгоритмы кардинально претерпели изменения со времен 70-х годов. С SSD разница может быть только в том, что после чтения кластера запись будет производиться уже в совсем другой, чтобы балансировать износ ячеек памяти, но это настолько глубоко скрыто от глаз даже на уровне API ОС, что не имеет смысла рассматривать.
Как и было написано выше - Seek() для любого размера файла будет занимать одинаковое время , так как по сути это лишь манипуляция с MFT в памяти.

0

belalugoci, речь была не поиск самих файлов по таблицам на диске и не про механизм этого поиска/чтения/записи.
Обсуждался сам факт работы с конкретным файлом при операциях дозаписи в него (в конец, в начало, середину..).
Т.е. чтобы дописать в конец - необходимо этот "конец" определить путем считывания (просматривания) файла.
Для вставки в середину - нужно найти эту "середину", затем "раздвинуть" блоки данных и вставить нужное между ними. Именно физически вставить, а не просто указать индексом в таблице что вот этот вот текст "находится в середине".

0

Не нужно файл просматривать весь, о чем он и написал. Seek все решает.

0

Таким образом происходит процесс поиска -> выделение "хвоста" от этого места и копирование его в буфер -> перезапись в это место нового фрагмента -> вставка скопированного в буфер "хвоста".
Т.е. частично или полностью файл перезаписывается.

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

0

А особенно удобно, когда лог файл превышает размер озу.

0

Сообщение от Rius Seek все решает.

Как он решает? Он решает задачу перенести указатель на n байт туда/сюда.
Мы же говорим про текстовый файл в котором, допустим, нужно сперва найти какое-то слово/символ. Это значит что файл нужно просматривать с начала и до нахождения этого, вплоть до конца, если такого не встретилось..

Добавлено через 1 минуту

Сообщение от Rius когда лог файл превышает размер озу.

а зачем лог держать все время в озу?

0

Мы говорим про запись логов.
Логи дописываются в конец файла. Никакого поиска и вставки в середину.

Я не знаю, что за идеи вы генерите.

0

Сообщение от Rius Я не знаю, что за идеи вы генерите.

Это я про ранние обсуждения..

Сообщение от Rius Никакого поиска

Файл открывается и производится поиск конца...
Про то что дозапись происходит в бинарном виде по таблицам MFT - нигде ни слова нет.
Вставка в конец самый "легкий" вариант такой обработки.

0

В случае логов "поиск" состоит в чтении данных из таблицы файлов, где точно указана длина файла и где искать последний байт. Зачем писать очевидное?
Это не чтение всего файла с самого начала до обнаружения признакам конца.

Логи в конец и пишутся.

Добавлено через 1 минуту
Тут иногда спрашивают, как вставить ноды в большой xml файл без чтения его всего в память.
Вот там всё плохо.

0

Rius, так я и не утверждаю что поиск == чтению. Тем не менее, создается поток в котором определяется этот конец. Ну или ребята из MS нагло врут в своей официальной документации...

Добавлено через 7 минут
Зная начало файла и его длину - можно сразу перенести указатель в конец, что собственно и делает Seek. Зачем употребили слово поиск в данном случае - загадка.

0

Раньше накопители были на магнитных лентах.

0

Сообщение от Rius Раньше накопители были на магнитных лентах.

Ну это существенно ничего не меняет, а даже наоборот - подтверждает саму суть слова Seek - "просматривать".

0

Сообщение от wizard41 речь была

я знаю о чем речь и мой ответ полностью раскрывает этот вопрос.

Сообщение от wizard41 Т.е. чтобы дописать в конец - необходимо этот "конец" определить путем считывания (просматривания) файла.

нет

Сообщение от wizard41 Для вставки в середину - нужно найти эту "середину"

для файловой системы нет понятия "вставить в середину", вам, как программисту, придется самостоятельно этот вопрос решать.
условно это будет Seek(N), Read(M), Seek(N), Write(K+M)
Где N это место вставки, M - все данные до конца файла, K - вставляемый кусок

Сообщение от wizard41 Именно физически вставить, а не просто указать индексом в таблице что вот этот вот текст "находится в середине".

именно вам, как программисту на высоком уровне абстракции ничего подобного делать не нужно, это сделает API, у вас только в качестве инструмента остаётся вызов конкретных функций. По сути это ничем не отличается от работы с массивами.

0

belalugoci, зачем вы мне объясняете эти вещи, которые я знаю еще "со школы"?
Я говорю, что они происходят "под капотом", чем иногда вызывают реальное перемещение байтов в файле на диске. Т.е. это работает не всегда так, как кажется.

Добавлено через 1 минуту
StringBuilder.Append

0

Сообщение от wizard41 Но работать всякий раз с файлом не выгодно, поэтому есть предположения, что при всех этих операциях удобнее считать весь файл целиком в память, затем произвести с ним необходимые операции и затем весь же записать обратно. Что фактически и означает перезапись файла целиком.

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

формально, если у вас файл - это контейнер, например это база данных, весит она например 5 Пб (петабайт), то вам проще делать SeekN) контролируя размер "окон" изменяемых данных. Но это уже абстракция как и файловая система, но на больших данных от этого не уйти, например так делает 1С, так делает MSSQL.

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

ну автор о таком вроде не говорил.
Но в любом случае для чтения файла достаточно буфера в 1 килобайт например и тут размер самого файла не имеет значения, а когда найдёте позицию в файле уже будете делать Seek() осмысленно.

Сообщение от wizard41 Файл открывается и производится поиск конца...

зачем? вы просто можете дописывать данные сразу в конец без всякого поиска, файловая система, ОС и её API это позволяют.

Сообщение от wizard41 Про то что дозапись происходит в бинарном виде по таблицам MFT - нигде ни слова нет.

а вам это и не нужно, это происходит автоматически, вы же находитесь выше по уровню абстракции при работе с файлами.

Сообщение от wizard41 Вставка в конец самый "легкий" вариант такой обработки.

выше я написал как можно сделать дозапись в середине без полного чтения БОЛЬШОГО файла. Для небольших файлов можно и всё в ОЗУ засунуть.

Сообщение от wizard41 Тем не менее, создается поток в котором определяется этот конец

https://learn.microsoft.com/ru... ew=net-8.0
вроде там всё просто и понятно, по сути работает как индексатор для массива.

Добавлено через 4 минуты

Сообщение от wizard41 зачем вы мне объясняете эти вещи, которые я знаю еще "со школы"?

ну пишете вы так словно только вчера появились в этом мире.

Сообщение от wizard41 Я говорю, что они происходят "под капотом"

ну если вы утверждаете что ОС бегает по файлу туда-сюда, то вы заблуждаетесь.

Сообщение от wizard41 Т.е. это работает не всегда так, как кажется

когда кажется - тогда крестятся. Я знаю как это работает еще с 80-х и пока нет причин сомневаться в том что основные принципы работы не изменились. Логи - это вообще задачка для первого класса, куда всё более масштабно например с СУБД. Не зря же HP и Oracle даже собственные файловые системы изобретали.

Сообщение от wizard41 StringBuilder.Append

Этот метод к обсуждению никак не подходит.

0

belalugoci, вы как-то не о том говорите. Мои тезисы относятся не столько к вопросу автора, сколько к затеянной некоторое время назад беседе в этой теме, относительно этих процессов.
И говорю я не за то как это работает в понимании инструкций к методам, а так, как происходит на самом деле с точки зрения файловой системы.

Добавлено через 4 минуты
Давно наткнулся на дебаты относительно этого, и там мало было сказать "дописывает в конец" и все. Т.е. ровно то, что сказано в оф. документации. А если копнуть глубже, то становится не так все гладко.

0

wizard41, тогда я не понимаю о чем вы говорите. Для меня процесс записи файлов не имеет никаких подводных камней и соотносится с документацией. Так уж сложилось что у нас HDD/SSD сильно обратно совместимы (с рядом оговорок конечно) с тем, как всё было устроено 40 лет назад. Поэтому нет особых сложностей подключить SSD (если точнее, то SD Card и CF Card) к платформе на i80286/386. Вероятно и SSD при делании через какой-то китайский контроллёр можно попробовать прикрутить. Я о том, что в этом аспекте технологии не сильно далеко ускакали от теории прошлого.

0