Возможные глюки при 100% загрузке процессора

← →
DVM © (2006-08-18 11:22) [0]

Есть некая программа. Программа пишет на диск в 20-40 открытых файлов. Пишет постоянно, по мере поступления данных. При запуске оной на компьютере достаточной мощности все нормально.
При запуске на слабом компьютере при загрузке 100% спустя несколько часов начинаются проблемы - "Недостаточно виртуальной памяти" - все останавливается.
Хочу выяснить - проблема все же в програме или так и должно быть при 100% загрузке.
Мое предположение, что из-за недостатка процессорного времени система откладывает и откладывает запись во временный буфер, но записать спустя время все равно не успевает. Это так?
Или все же это проблема программы?

← →
boriskb © (2006-08-18 11:26) [1]

Проверь свое предположение.
Периодически принудительно сбрасывай буфер в файл

← →
Ketmar © (2006-08-18 11:26) [2]

это memory leak.

← →
Kolan © (2006-08-18 11:28) [3]

> "Недостаточно виртуальной памяти"

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

← →
Чапаев © (2006-08-18 11:31) [4]

Ну ведь если запускать при малой загрузке проца, то проблемы не видно...

← →
DVM © (2006-08-18 11:32) [5]

> это memory leak.

Почему проявляется только при 100% загрузке на слабых машинах?
Ни объекты, ни память, ни дискрипторы (счетчики) не растут во время работы программы.

> Периодически принудительно сбрасывай буфер в файл

Я попробую использовать флаг FILE_FLAG_WRITE_THROUGH в CreateFile - может поможет. Ждать только долго надо. Эмуляция ситуации на мощной машине не получается. Даже если я проц гружу на 100 процентов.

> Процессор то тут причем.. скорее всего файлы разростаются
> в размере, а ты их в памяти держишь....

Почему в памяти? На диск пишутся. Порциями и небольшими.

← →
cyborg © (2006-08-18 11:35) [6]

Может на слабой тачке ОС другая? Последние версии всяко лучше работают.

← →
Ketmar © (2006-08-18 11:36) [7]

> [4] Чапаев © (18.08.06 11:31)
сильно подозреваю, что на мощном компе просто памяти побольше. %-)

← →
Чапаев © (2006-08-18 11:37) [8]

> Я попробую использовать флаг FILE_FLAG_WRITE_THROUGH в CreateFile
> - может поможет. Ждать только долго надо. Эмуляция ситуации
> на мощной машине не получается. Даже если я проц гружу на
> 100 процентов.

А на эмуляторе? Памяти поменьше...

Хотя, в принципе, и на реальной машинке с BURMMEMORY поиграться можно, сразу машинка "ослабеет". ;-)

← →
DVM © (2006-08-18 11:39) [9]

> сильно подозреваю, что на мощном компе просто памяти побольше.

Нет, дело не в этом. Памяти одинаково.
На мощном компьютере программа работает сутками без проблем.
И см. [5]
> Ни объекты, ни память, ни дискрипторы (счетчики) не растут
> во время работы программы

← →
DVM © (2006-08-18 11:44) [10]

Вот процедура записи на диск:
Добавляет данные в два открытых файла (файл данных и индексный файл, подробнее объяснять не буду, нет смысла и из кода понятно).
Ранее указанные файлы созданы другой процедурой.

function TScene.WriteFrame(const Buffer: PChar; Count: Cardinal): boolean; var dwPointer: DWORD; NumberOfBytes: Cardinal; sz: Int64; st: TDateTime; begin Result := false; if FVideoFileHandle <> INVALID_HANDLE_VALUE then begin sz := FSize; dwPointer := SetFilePointer(FVideoFileHandle, Int64Rec(sz).Lo, @Int64Rec(sz).Hi, FILE_BEGIN); if (dwPointer <> $FFFFFFFF) then begin if WriteFile(FVideoFileHandle, Buffer^, Count, NumberOfBytes, nil) then if NumberOfBytes = Count then begin FSize := FSize + NumberOfBytes; if FIndexFileHandle <> INVALID_HANDLE_VALUE then begin dwPointer := SetFilePointer(FIndexFileHandle, 0, nil, FILE_END); if (dwPointer <> $FFFFFFFF) then begin st := Now; sz := FSize; if WriteFile(FIndexFileHandle, st, 8, NumberOfBytes, nil) then if NumberOfBytes = 8 then begin FIndexSize := FIndexSize + NumberOfBytes; if WriteFile(FIndexFileHandle, sz, 8, NumberOfBytes, nil) then if NumberOfBytes = 8 then begin FIndexSize := FIndexSize + NumberOfBytes; Result := true; end; end; end; end; end; end; end; end;

← →
Ketmar © (2006-08-18 11:51) [11]

гы. так это ещё и работа с видео? %-)
вообще, может быть, что винде просто не хватает времени на растусовку страниц в своп, и она поступает умно -- увеличивает своп. %-)

← →
Чапаев © (2006-08-18 11:54) [12]

> FIndexSize := FIndexSize + NumberOfBytes;

Это так и задумано? Записываешь дважды, IndexSize наращиваешь один раз. Хотя, конечно, это вряд ли относится к решаемой проблеме...

← →
Чапаев © (2006-08-18 11:54) [13]

Тьфу. Предыдущий пост не читайте, пожалуйста...

← →
DVM © (2006-08-18 11:58) [14]

> Ketmar © (18.08.06 11:51) [11]

Не совсем с видео, но что-то в этом духе.
Обработкой видеопоследовательностей программа не занимается. Ее дело принять видеопоток с HTTP сервера и записать. Т.е нагрузку создает только сеть и запись на диск.
Все это проверяется на очень своеобразном копьютере с процессором VIA 533 Мгц.

← →
Ketmar © (2006-08-18 11:58) [15]

> [13] Чапаев © (18.08.06 11:54)
поздняк. я уже... %-)

← →
Ketmar © (2006-08-18 11:59) [16]

> [14] DVM © (18.08.06 11:58)
честно говоря, никогд так процессор не загружал. дома попробую, если не забуду и не лень будет. %-)

← →
tesseract © (2006-08-18 12:00) [17]

> Т.е нагрузку создает только сеть и запись на диск.

Если не диск, то возможно сеть и глючит.

← →
DVM © (2006-08-18 12:03) [18]

> Если не диск, то возможно сеть и глючит.

Сеть это отдельная песня, алгоритм там очень сложный, но замечено, что если запись отключить, проблем вроде бы нет (я не замечал).

← →
tesseract © (2006-08-18 13:43) [19]

> DVM © (18.08.06 12:03) [18]

Есть некое предположение, что просто глючит дисковый кэш.......
а оперативки добавить никак?

← →
Desdechado © (2006-08-18 13:54) [20]

> а оперативки добавить никак?
Отодвинуть появление проблемы на пару суток?

← →
Мефисто (2006-08-18 19:16) [22]

> tesseract © (18.08.06 13:43) [19]

> Есть некое предположение, что просто глючит дисковый кэш.
> ......

Растет не по дням, а по часам?

> [22] Мефисто (18.08.06 19:16)

не успевает сброситься :-) на диск. Такое бывает.

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

> DVM © (18.08.06 11:32) [5]

>Я попробую использовать
> флаг FILE_FLAG_WRITE_THROUGH в CreateFile - может поможет.
> Ждать только долго надо. Эмуляция ситуации на мощной машине
> не получается. Даже если я проц гружу на 100 процентов.

А просто во время работы периодически вызывать функцию FlushFileBuffers не пробовал?

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

А вспомнить, для примера, клиента пиринговых сетей. Например, того-же eMule. Один коннект, один поток с записью в файл по карте закачки.
По-умолчанию - число соединений ~300. Работает и 600 на, отнюдь, не выдающейся машине (Sempron 2800+, IDE HDD Maxtor).
Освобождать ресурсы надо вовремя. Процессор и диск здесь ни при чем.

> [24] Пусик © (19.08.06 14:48)

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

> А вспомнить, для примера, клиента пиринговых сетей.

Неудачное сравнение. Потоков записи на диск то у него много, да только скорости маленькие.
У меня 150-200 кбайт сек на коннект. При этом таких конеектов 25 допустим. Кроме того данные надо принять, проверить корректность, декодировать.

> Работает и 600 на, отнюдь, не выдающейся машине (Sempron
> 2800+, IDE HDD Maxtor).

Сравнил божий дар с яичницей. Я проверяю на VIA 533. Это раз в 50 медленнее будет ИМХО.

> Освобождать ресурсы надо вовремя.

Читайте предыдущие мои посты. Ни память, ни дискрипторы, ни объекты никакие НЕ РАСТУТ во время выполнения программы. Я специально даже стал вести лог ради этого. Просто в один момент появляется сообщение Не хватает виртуальной памяти.

> > Освобождать ресурсы надо вовремя.

Почему проявляется только при дительной 100% загрузке?
Если загрузку сделать, скажем, 70% глюк не возникнет никогда. Я неделю ждал специально.

Возможные глюки при 100% загрузке процессора Найти похожие ветки