есть некая готовая библиотека, довольно таки большая. Все работает замечательно за исключением одного момента — все данных хранятся в памяти (промах архитекторов). С этим возникают некоторые проблемы — при больших объемах данных библиотека упирается в размеры доступной памяти. Возникла идея сделать фикс — выгружать не используемые блоки данных на диск. Вижу несколько путей решения:
— написать свой менеджер памяти / доработать существующие
Минус идеи — слишком много исправлений по всей библиотеке (замена всех вызовов new/delete/malloc/free своими)
— переход на свои smart-указатели (в оригинале используется boost::shared_ptr<>) либо доработка boost::shared_ptr<>
Минус идеи — слишком много исправлений по всей библиотеке, возможные конфликты с другим кодом (в случае доработки boost::shared_ptr<>)
— реализация менеджера внутри центральных объектов (например, есть некая таблица, хранящая все объекты, объекты добавляются через API таблицы)
Минус идеи — не понятно, как вычислять размер объектов (sizeof(obj) не всегда будет верным)
Если кто сталкивался с подобной задачи, пожалуйста, отпишитесь по поводу возможных решений, сложностей реализации, линками на готовые решения/идеи.
Здравствуйте, SilentNoise, Вы писали:
SN>Здравствуйте, Аноним, Вы писали:
SN>А почему бы не добавить свапа в системе? ОС сама выгрузит туда редко используемые данные.
Поддерживаю. Система, скорее всего, справится с выгрузкой лучше самописного менеджера. Если упираетесь в адресное пространство, то лучше перевести программу на x64 платформу. Это будет намного проще переработки всей подсистемы загрузки/хранения данных
Здравствуйте, SilentNoise, Вы писали:
SN>А почему бы не добавить свапа в системе? ОС сама выгрузит туда редко используемые данные.
Я так понял что он упирается в адресное пространство на процесс в x32.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Аноним, Вы писали:
А>Доброе время суток.
А>есть некая готовая библиотека, довольно таки большая. Все работает замечательно за исключением одного момента — все данных хранятся в памяти (промах архитекторов). С этим возникают некоторые проблемы — при больших объемах данных библиотека упирается в размеры доступной памяти. Возникла идея сделать фикс — выгружать не используемые блоки данных на диск.
Выгружать неиспользуемые блоки на диск — это фактически принцип работы файла подкачки. Решение его использовать не подходит? Им же можно даже ограниченно управлять. Вызываешь madvise(.., MADV_DONTNEED) и указанный регион памяти выгружается на диск. За всем следит OC и библиотеку модифицировать не обязательно — красота. Хотя если у тебя windows, то там по-моему аналог madvise не доступен, а следовательно придётся целиком полагаться на менеджер ОС — тут уже эффективность будет от него зависеть.
А> — написать свой менеджер памяти / доработать существующие А> Минус идеи — слишком много исправлений по всей библиотеке (замена всех вызовов new/delete/malloc/free своими)
Можно доработать существующий. Скажем, можно довольно просто заменить системный вызов по запросу памяти на вызов отображения файла в память (если оригинальный менеджер памяти использовал mmap, то это вообще только замена двух параметров в вызове функции). Ну то есть по сути получится тот же файл подкачки, но локальный для приложения. Заменять new/malloc на свои в этом случае тоже не обязательно. Работать будет так же — если в системе заканчивается оперативная память, то ОС будет выгружать страницы в этот файл, ну и вручную через madvise тоже можно управлять сбросом и загрузкой с диска.
On 12/23/2011 01:48 PM, Аноним 431 wrote:
> есть некая готовая библиотека, довольно таки большая. Все работает замечательно > за исключением одного момента — все данных хранятся в памяти (промах > архитекторов). С этим возникают некоторые проблемы — при больших объемах данных > библиотека упирается в размеры доступной памяти.
В какой размер памяти она упирается ?
Возникла идея сделать фикс — > выгружать не используемые блоки данных на диск. Вижу несколько путей решения: > — написать свой менеджер памяти / доработать существующие
Идея дурацкая. Лучше перенести всё на платформу с поддержкой виртуальной
памяти. это и все современные Win, и любой Lin / Unix.
Если не хватит 32битной памяти -- перенесите на 64 бита.
> Минус идеи — слишком много исправлений по всей библиотеке (замена всех вызовов > new/delete/malloc/free своими)
Это как раз не проблема. Минус идеи в том, что выделение памяти -- не то
место, где ты сможеш выгруженную память подгружать обратно.
Это надо делать при доступе к памяти, при чтении даже.
Это тебе надо грубо говоря заменить весь доступ к внутренним массивам
данных на вызовы своих функций, где ты будеш проверять, что что-то не
загружено, и подгружать (выгружая другое).
Либо -- написать свой менеджер виртуальной памяти. А нафига его
писать, если они уже есть ?
...
Это всё неверные идеи. Тебе надо переопределять ДОСТУП к памяти, а не
выделение её. Мэнеджера памяти тут мало.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: менеджер памяти с выгрузкой данных на диск
От:
Аноним
Дата:
23.12.11 10:32
Оценка:
Здравствуйте, watch-maker, Вы писали:
WM>Выгружать неиспользуемые блоки на диск — это фактически принцип работы файла подкачки. Решение его использовать не подходит? Им же можно даже ограниченно управлять. Вызываешь madvise(.., MADV_DONTNEED) и указанный регион памяти выгружается на диск. За всем следит OC и библиотеку модифицировать не обязательно — красота. Хотя если у тебя windows, то там по-моему аналог madvise не доступен, а следовательно придётся целиком полагаться на менеджер ОС — тут уже эффективность будет от него зависеть.
да, целевая платформа Windows.
А>> — написать свой менеджер памяти / доработать существующие А>> Минус идеи — слишком много исправлений по всей библиотеке (замена всех вызовов new/delete/malloc/free своими) WM>Можно доработать существующий. Скажем, можно довольно просто заменить системный вызов по запросу памяти на вызов отображения файла в память (если оригинальный менеджер памяти использовал mmap, то это вообще только замена двух параметров в вызове функции). Ну то есть по сути получится тот же файл подкачки, но локальный для приложения. Заменять new/malloc на свои в этом случае тоже не обязательно. Работать будет так же — если в системе заканчивается оперативная память, то ОС будет выгружать страницы в этот файл, ну и вручную через madvise тоже можно управлять сбросом и загрузкой с диска.
интересно, надо будет погуглить статьи на данную тему.
Re[3]: менеджер памяти с выгрузкой данных на диск
От:
Аноним
Дата:
23.12.11 10:37
Оценка:
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, SilentNoise, Вы писали:
SN>>А почему бы не добавить свапа в системе? ОС сама выгрузит туда редко используемые данные. BBI>Я так понял что он упирается в адресное пространство на процесс в x32.
сейчас провожу тесты, что бы понять чего именно не хватает.
Здравствуйте, MasterZiv, Вы писали:
MZ>On 12/23/2011 01:48 PM, Аноним 431 wrote:
>> есть некая готовая библиотека, довольно таки большая. Все работает замечательно >> за исключением одного момента — все данных хранятся в памяти (промах >> архитекторов). С этим возникают некоторые проблемы — при больших объемах данных >> библиотека упирается в размеры доступной памяти.
MZ>В какой размер памяти она упирается ?
создается PDF документ с 10000+ страницами.
MZ> Возникла идея сделать фикс — >> выгружать не используемые блоки данных на диск. Вижу несколько путей решения: >> — написать свой менеджер памяти / доработать существующие
MZ>Идея дурацкая. Лучше перенести всё на платформу с поддержкой виртуальной MZ>памяти. это и все современные Win, и любой Lin / Unix. MZ>Если не хватит 32битной памяти -- перенесите на 64 бита.
библиотека существует в 2х вариантах, уточняю, какой пользуется кастомер.
>> Минус идеи — слишком много исправлений по всей библиотеке (замена всех вызовов >> new/delete/malloc/free своими)
MZ>Это как раз не проблема. Минус идеи в том, что выделение памяти -- не то MZ>место, где ты сможеш выгруженную память подгружать обратно. MZ>Это надо делать при доступе к памяти, при чтении даже. MZ>Это тебе надо грубо говоря заменить весь доступ к внутренним массивам MZ>данных на вызовы своих функций, где ты будеш проверять, что что-то не MZ>загружено, и подгружать (выгружая другое).
MZ>Либо -- написать свой менеджер виртуальной памяти. А нафига его MZ>писать, если они уже есть ?
MZ>...
MZ>Это всё неверные идеи. Тебе надо переопределять ДОСТУП к памяти, а не MZ>выделение её. Мэнеджера памяти тут мало.
Здравствуйте, <Аноним>, Вы писали:
SN>>>А почему бы не добавить свапа в системе? ОС сама выгрузит туда редко используемые данные. BBI>>Я так понял что он упирается в адресное пространство на процесс в x32.
А>сейчас провожу тесты, что бы понять чего именно не хватает.
Дык а чего там тестить?
Посмотри VMMap что у тебя в памяти творится или ProceXP.
Процесс х32 или х64?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MasterZiv, Вы писали:
MZ>On 12/23/2011 02:44 PM, Hydrophobia wrote:
>> MZ>В какой размер памяти она упирается ? >> >> создается PDF документ с 10000+ страницами.
MZ>Сколько памяти-то ей надо ? Сколько у неё есть и сколько ей надо, MZ>чтобы она отработала ?
на данный момент конвертер emf2pdf съедает 6.2GB RAM, система скоро полезет в своп (900MB осталось), тестирую на win7x64/8GB, генерирую PDF в 10000 страниц из EMF. ожидаю выделения 10-12 GB на данный процесс.
MZ>PDF создаётся поточными алгоритмами, не более 1 страницы в MZ>памяти, плюс всякая информация о том, как форматировать, MZ>это немного и быстро достаточно.
А>>сейчас провожу тесты, что бы понять чего именно не хватает. BBI>Дык а чего там тестить? BBI>Посмотри VMMap что у тебя в памяти творится или ProceXP. BBI>Процесс х32 или х64?
тестирую на x64 и похоже, что все ОК. Видимо проблема только на х32.
Здравствуйте, Hydrophobia, Вы писали:
H>на данный момент конвертер emf2pdf съедает 6.2GB RAM, система скоро полезет в своп (900MB осталось), тестирую на win7x64/8GB, генерирую PDF в 10000 страниц из EMF. ожидаю выделения 10-12 GB на данный процесс.
Ыыыыыы!!!
Капец, зачем ему там столько памяти то?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Banned by IT, Вы писали:
H>>на данный момент конвертер emf2pdf съедает 6.2GB RAM, система скоро полезет в своп (900MB осталось), тестирую на win7x64/8GB, генерирую PDF в 10000 страниц из EMF. ожидаю выделения 10-12 GB на данный процесс. BBI>Ыыыыыы!!! BBI>Капец, зачем ему там столько памяти то?
ну вот и я о том же. правильней было бы выгружать уже созданные PDF страницы на диск, а в памяти держать только заголовок PDF и не полные страницы (если такое возможно в формате PDF).
Создавал PDF с разрешением 600x600 DPI, размер бумаги 8.5"x11" (Letter).
On 12/23/2011 07:41 PM, Hydrophobia wrote:
> на данный момент конвертер emf2pdf съедает 6.2GB RAM, система скоро полезет в > своп (900MB осталось), тестирую на win7x64/8GB, генерирую PDF в 10000 страниц из > EMF. ожидаю выделения 10-12 GB на данный процесс.
Я тогда вообще не понимаю, что тебе нужно. 64 бита -- это офигенно много памяти
для приложения (если оно конечно 64битное, кстати). Виртуальная память есть,
тебе достаточно только докупить физ. памяти и втавить, или подождать
пока просвопит.
Или думать, на кой тебе PDF в 10000 страниц.
(что тоже достаточно безумная мысль).
