Error Occurred при экспорте Большого проекта

Целый день сегодня промучился. Уже установил чистую зебру, чтобы исключить вылеты. Но все равно, 3 раза на старой зебре вылетало, и на новой 2 раза.

Жду около 1 часа пока загрузится проект в программу. Открываю в режиме «Большой проект» и в Обычном тоже пробовал. Все ок. Нажимаю, экспорт в WopdPress, размер файла 50Мб. Через 20 минут окно:



Обидно, месяц работал, собирал материалы(таких сайтов будет штук 20). А тут такое.

Режим «Большой проект» не гарантирует, что этой ошибки не будет. Принцип использования памяти другой, но ОС всё равно может по какой-то причине не выделить программе необходимую ей оперативную память. Посоветовать могу лишь разбить проект.

P.S. Тему перенес в вопросы.

Поставил на разбивку, уже час жду. Может стоит подумать над решением проблемы? А то не дело, ждать загрузки проекта 1 час, разбивка 1 час, экспорт и сборка ~ 1 час, делаешь-делаешь проект а в конце неизвестность… Больше ждешь, чем работаешь.

Посчитал сколько записей получилось экспортировать, пока не выскочило «Зловещее окно». В xml файлах title — 79200 штук.

А вообще, в проекте 140к записей, и коментов 400к.

Есть только один способ избавится от этой проблемы — это не хранить данные в памяти, а хранить их на диске. Я проводил эксперимент с таким подходом, скорость всех инструментов падала на порядок. В результате это будет еще медленнее.

admin в своем сообщении писал(а):Есть только один способ избавится от этой проблемы — это не хранить данные в памяти, а хранить их на диске.

Не понял по какому принципу, поделитесь ссылкой?.. А то я уже ищу, как в семерке увеличить память. forum.ixbt.com/topic.cgi?id=22:75914 тут пытаются, у кого-то что то получилось, но сложновато, ничего не понятно.

Еще статейку нашел. Может вам будет полезна (я в ней ничего не понял) compress.ru/article.aspx?id=20804

Кстати, разбивка проекта наверно зависла, хотя не знаю, может и не зависла. Выставил в плагине галочку «Выбирать посты Случайным образом» уже идет 7-ой час, Зеброид «Не отвечает», но процессор грузит одно ядро на 100 процентов.

Не понял по какому принципу, поделитесь ссылкой?

Это я говорил о том, что единственный способ избавиться от проблемы нехватки памяти состоит в том, чтобы изменил алгоритм работы программы таким образом, чтобы проект не выгружался в память, а хранился на винтчестере. У меня была попытка сделать такой алгоритм, но тесты показали очень печальные данные о быстродействии программы в таком случае. Приходится выбирать между двух зол. Если я сделаю так, чтобы данные хранились на винтчестере, то проблемы будут у всех: и тех, кто делает маленькие проекты, и у тех, кто большие. Сейчас проблемы только у тех, кто делает очень большие проекты и они по крайней мере имеют обходные пути (проект изначально можно делать в виде нескольких проектов поменьше и обрабатывать их с помощью инструмента «Обработка нескольких проектов»).

А то я уже ищу, как в семерке увеличить память. forum.ixbt.com/topic.cgi?id=22:75914 тут пытаются, у кого-то что то получилось, но сложновато, ничего не понятно.

Судя по тому, что там пишут люди — они не в теме. Количество оперативной памяти для 32 битного процессора ограничено не искусственно, это ограничение существует потому, что 32 битный процесс имеет 32-битные указатели на ячейки памяти, количество которых ограничено 2 млрд. Никакие ключи в реестре не изменят того, что число (указатель на ячейку памяти) не может быть больше определенного порога.

Как я уже говорил, режим «Большой проект» работает по другому, он для каждой записи в проекте просит ОС выделить отдельный кусок памяти, который в свою очередь ограничен 2 Гб. Этого должно быть достаточно, чтобы не иметь проблем со свободной памятью. Но процессом выделения занимается ОС, и если она по какой-то причине отказала программе в выделение очередного куска — значит со стороны программы ничего нельзя поделать. Теоретически, ОС должна давать программе столько памяти, сколько ей нужно в пределах свободной оперативки + виртуальной памяти, но на практике это не всегда так. Возможно увеличение количества виртуальной памяти решит этот вопрос, но виртуальная память — это место на винтчестере, а это значит что проблема быстродействия на проектах, которые её используют будут стоять еще острее, так как мало того, что проект очень большой и его обработка занимает много времени, так еще данные находятся на медленных носителях.

Еще статейку нашел. Может вам будет полезна (я в ней ничего не понял) compress.ru/article.aspx?id=20804

Не поможет, я это всё прекрасно знаю, дело не в утечках памяти.

Кстати, разбивка проекта наверно зависла, хотя не знаю, может и не зависла. Выставил в плагине галочку «Выбирать посты Случайным образом» уже идет 7-ой час, Зеброид «Не отвечает», но процессор грузит одно ядро на 100 процентов.

Не совсем понял взаимосвязи между разбивкой проекта и выбором случайных постов.

admin в своем сообщении писал(а):

Не совсем понял взаимосвязи между разбивкой проекта и выбором случайных постов.

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



Вчера в 22-00, сейчас 13-00, т.е прошло 15 часов, Зеброид не отвечает до сих пор, процессор грузит.

Этот плагин не для вашего случая. Вам нужен инструмент "Разбить / объединить проект"

Вот это я намучаюсь с экспотом(((( Не хочется, мне мучатся.

А если и использовать флаг IMAGE_FILE_LARGE_ADDRESS_AWARE? Прочитал тут forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html

И еще, есть приложение, читал тут www.nextwindows.ru/advices/page,1,2,979-ispolzovanie-4-gb-pamyati-32-bitnymi-prilozheniyami-v-64-bitnoj-os.html#comment — я думал очередной «взброс пустышка», но в этой статье forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html — есть упоминание о ней.

А если и использовать флаг IMAGE_FILE_LARGE_ADDRESS_AWARE? Прочитал тут forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html

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

И еще, есть приложение, читал тут www.nextwindows.ru/advices/page,1,2,979-ispolzovanie-4-gb-pamyati-32-bitnymi-prilozheniyami-v-64-bitnoj-os.html#comment — я думал очередной «взброс пустышка», но в этой статье forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html — есть упоминание о ней.

Можете попробовать, но на сколько я понял этот патч делает тоже самое, что и флаг IMAGE_FILE_LARGE_ADDRESS_AWARE.