Проблемы с памятью

> Но быстр в реализации.

Нет!

FIFO по сути своей -- просто последовательный файл. ПРОСТО писАть на диск / читать с диска -- и проще, и оптимальнее, чем поднимать сложную библиотеку типа Берклевских хэшей и "стрелять" ею по линейному списку. Операционка сама что надо скэширует, а хэши тут не нужны вообще.

PPS. Если общее решение не годится, а нужно конкретное решение твоей специальной задачи - тогда нужно конкретное описание твоей специальной задачи. Imho.

> Если общее решение не годится, а нужно конкретное решение твоей специальной задачи - тогда нужно конкретное описание твоей специальной задачи.

Во, ИМХО хорошо сказал: http://www.linux.org.ru/jump-message.jsp?msgid=3472425&cid=3473988

> FIFO по сути своей -- просто последовательный файл. ПРОСТО писАть на диск / читать с диска -- и проще, и оптимальнее, чем поднимать сложную библиотеку типа Берклевских хэшей.

Я же писал в одном из постов что берклевская _очередь_, это и есть то что ты описываешь (все записи последовательно пишутся на диск). Но в данном случае у тебя есть функции удаления уже записаных данных в базу, которое в случае ручной реализации придется делать (если не использовать циклический буфер, но тогда его надо выбрать настолько большим, чтоб во время пика нагрузки не произошло ошибки). Да ещё не требуется отладки "ручной реализации" - так как в bdb - уже всё отладили для тебя.

> Я же писал в одном из постов что берклевская _очередь_, это и есть то что ты описываешь...

Я истощён этим спором :)

Если тебе так хочется вместо двух операторов fputs() и fgets() поднимать мощную систему, которая поддерживает возможность одновременного доступа многих пользователей, реализует поддержку транзакций на промышленном уровне и восстановление баз данных после системных и дисковых сбоев, способную обслуживать тысячи процессов или потоков, одновременно манипулирующих базами данных размером в 256 терабайт, -- вперёд!.

>> Я же писал в одном из постов что берклевская _очередь_, это и есть то что ты описываешь...

>Я истощён этим спором :)

>Если тебе так хочется вместо двух операторов fputs() и fgets() поднимать мощную систему, которая поддерживает возможность одновременного доступа многих пользователей

Ни FIFO, ни другое дисковое хранилище автору топика не подойдет - раньше засиралось ОЗУ, будет засираться HDD, только и всего. Надо добиваться того чтобы самое медленное звено в цепочке работало с приемлемой скоростью и имело запас перформанса, вот и все.

/thread

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

Продолжим развитие libastral :)

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

Прикупаем еще один такой же диск в качестве скретча, и проблема решена.

:-)

> Если скорость генерации неких событий заведомо больше скорости их обработки, то единственный выход -- куда-нибудь их сдемпфировать.

Ненене, это не выход. Если генерация _устойчиво_ быстрее записи, то проблема неразрешима. Вот если генерация идет "вспышками" (пусть даже длинными), но при этом средняя скорость генерации ниже скорости записи, большой буфер поможет.

> Если скорость генерации неких событий заведомо больше скорости их обработки, то единственный выход -- куда-нибудь их сдемпфировать.

Обычно люди для начала начинают оптимизировать обработчик событий =)

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

>Если скорость генерации неких событий заведомо больше скорости их обработки, то единственный выход -- куда-нибудь их сдемпфировать.

Я такую проблему однажды успешно решил аккуратно переработав алгоритм, и заодно убрал всякие демпфирующие костыли и прочие козявки. Оталось глубокое удовлетворение что я работу сделал на совесть и сервис теперь надежно и с минимальной задержкой обрабатывает платежи в режиме 24/7. Так что особого сочувствия проблема топикстартера и метод ее решения у меня не вызывает. Задача может быть либо рантаймовая либо нет. Если она не рантамовая то она будет работать со скоростью самого медленного звена. Если скорость не устраивает, надо оптимизировать алгоритм или менять бизнес-логику.

> Если генерация _устойчиво_ быстрее записи, то проблема неразрешима.

Я сформулировал условия при которых она разрешима.

Посмотри на LHC (Большой Адронный Коллайдер). Тама скорость генерации событий много лет будет превышать скорость обработки -- ничего, всё работает...

> Посмотри на LHC (Большой Адронный Коллайдер). Тама скорость генерации событий много лет будет превышать скорость обработки -- ничего, всё работает...

А потом еще больше лет скорость обработки будет превышать скорость генерации? Ну да, при наличии ОЧЕНЬ большого буфера (на "много лет") всё получится. Но вот только вряд ли UVV может позволить себе буфер емкостью даже несколько часов :)

>LHC (Большой Адронный Коллайдер) <skipped> -- ничего, всё работает...

Машина времени ЛОР-а?

> Но вот только вряд ли UVV может позволить себе буфер емкостью даже несколько часов :)

Ну я же сформулировал достаточные условия!

Из его вопроса можно предположить, что данные спасаются в базу, физически расположенную на локальном диске. Следовательно, емкости диска достаточно для хранения _всех_ данных, поступивших за _бесконечное_ время!

Удвоим дисковое пространство -- получим буфер, теоретически достаточный для спасения _всех_ данных, даже при нулевой скорости их обработки!

Да, надеюсь, ты понимаешь, что это я просто в пространство теоретизирую. В реальности, скорее всего, решение его проблемы лежит в ускорении работы с БД и / или не использования ГНУтого аллокатора, поскольку он часто сильно фрагментирует, а free() по определению шибко тормознутая.

>> LHC (Большой Адронный Коллайдер) <skipped> -- ничего, всё работает...

>Машина времени ЛОР-а?

Нет, пуск LHC состоялся, вся инфраструктура давно работает, а сам он тупо механически сломался: весь жидкий гелий потеряли, и в данный момент новый забульбучивают -- надеюсь, понятно, что к системам обработки данных это отношения не имеет?

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

...и как раз это он не успевает. Поэтому его "демпфирование" должно делаться в ОП, которой ему и на несколько часов не хватит :)

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

Да понятно. Это первое, что ему предложили :)

>...и как раз это он не успевает. Поэтому его "демпфирование" должно делаться в ОП,...

Спасение в БД сопровождается огромным оверхэдом на поддержку организации даных, особенно если это реляционная БД, на всякие транзакции и прочее журналирование. Просто последовательные операции с дисковыми записью / чтением в разы быстрее.

> Спасение в БД сопровождается огромным оверхэдом на поддержку организации даных

Это всё понятно, но по условиям задачи данные должны оказаться в БД. Кроме того, прозреваю систему реального времени :) ну или как минимум взаимодействия с датчиками (т.е. ее нельзя приостановить и ее данные нужны быстро).

> Просто последовательные операции с дисковыми записью / чтением в разы быстрее.

А здесь мы ступаем на зыбкую почву предположений :) Может, ускорение в разы спасет, а может, и нет.

> А здесь мы ступаем на зыбкую почву предположений :) Может, ускорение в разы спасет, а может, и нет.

Да, естественно!

Раз уж мы занялись libastral, я и предложил такое решение как одно из возможных.