Алгоритмы машинного обучения, импорт миллионов документов с выявлением связей (часто можно сильно ускорить за счет оперативки), также pycharm и phpstorm пару-тройку гига оперативы сжирают, виртуальные машины жрут, эластиксерч прожорлив, постгес и mysql кушать хочеться (особенно при работе с десятком миллионов текстов) ну и плюс десяток рабочих столов с несколькими браузерами и сотнями открытых вкладок. Короче, 32 гиг оперативы мне уже иногда не хватает.
У меня не классическая вебразработка. Использую всякие статистические алгоритмы и алгоритмы ИИ на больших корпусах текстов. А они отнимают много ресурсов.
Этим и приходится заниматься. Хотя... если б было 128 гиг оперативы, то во многих разовых случаях можно было бы и не заморачиваться с оптимизацией.
О, это ценные сведения. Учту, спешить не буду. Пока наверно ограничусь покупкой SSD - по любому надо будет на дебиан 9 переходить, вот на новые диски и установлю.
Stek, я вроде нашел вероятную причину. Знал ведь о ней, но подзабыл. Я импорт делаю через manage.py, так вот там в нем оказалась прописана ссыль на конфиг "dev", в котором DEBUG=True, а в этом случае ведется отладочный лог SQL-запросов, что при большом объеме запросов приводит к утечкам памяти и прочим неприятностям. В общем я грешу на это. С выключенной отладкой база разрастается до 40Гб примерно. Но это еще хоть объяснимо, что 10Гб (вернее 20Гб - там тест дублируется) разрастаются до 40Гб. А то что VACUUM (FULL) сокращает базу до 2.7Гб, я думаю из за того, что он данные вроде как в бинарном виде хранит, т.е. похоже сжимает прилично.
Пробовал. Но сильной разницы в разрастании базы не увидел (хотя наверно она есть). В один поток я использовал @transaction.atomic на всю ф-цию импорта документа. Но в один поток импорт очень долго идет, хотя надежно. Пробовал в шесть потоков (на шестиядерном интеле) запускать, правда пришлось использовать табличные блокировки, а от транзакций отказался, да и в целостности дерева не уверен после такого импорта, хотя в разы быстрее конечно.
После вставки один раз каждый объект перезаписывается. Так логика сильно упрощается, т.к. только после вставки объекта в дерево можно на полную мощь пользоваться функционалом, предоставляемым деревом. Т.е. после вставки в дерево (insert), производятся некоторые вычисления и апдейт.
Всё что касается атовакуума осталось в настройках по дефолту (postgres версии 9.4), я их не трогал. Хотя в процессе импорта (он долго идет) вручную в консоли postgres VACUUM запускал несколько раз - база продолжала расти, только VACUUM (FULL) помогал.
Средний размер - несколько килобайт или десятков килобайт, иногда до 1-8 мегабайт текста.
Надеюсь :) В джанго нет команды явного закрытия транзакции, в документации написано, что она автоматически закрывается по окончании атомарного блока кода.---------- Добавлено 29.07.2017 в 14:58 ----------И еще пара вопросов:
1) Я заметил, скорость импорта заметно падает после середины импорта. Может это быть связано с разрастанием базы? Или в сторону индексов смотреть?
2) Vacuum (FULL) можно запускать при импорте? Кроме временной задержки (из-за полной блокировки) ничего деструктивного для импорта не должно произойти?
Спасибо. И с индексацией с продвижением проблем нет?
Точно не будет рубить? Это ключевой вопрос. В метрике например для сбора статистики он ведь рубит урл. Вот и получается, что с одной стороны ему надо дать правильно структурированный урл, а с другой стороны, что он подумает о глубокой вложенности...
Еще забыл уточнить: в слагах урла многие термины будут с дефисом. В первом варианте это будет нормально выглядеть, а во втором визуально структуру будет сложно понять, т.к. дефис будет соединять не только категории, но и термины в названиях категорий.
Content-pro, Да, в первом варианте можно легко любую логику на урлы завязать, например если в друпале урлы сделаны по первому варианту и надо показать блок с объявлением в подразделе слонов и глубже, то в настройках видимости блока достаточно прописать:
zoopark/zveri/slony/*
Первый вариант вызывает сложности с перемещением товаров между категориями, но в моем случае этого не будет.---------- Добавлено 15.07.2017 в 23:20 ----------
В символах длина урла во всех вариантах не очень большая - до 255 символов думаю будет, но уровней вложенности в урле будет до 6-7.
В общем то первый и второй вариант визуально одинаковые. Но что лучше для поисковиков? С одной стороны поисковики пытаются отследить вложенность по урлу (это и в метрике видно), с другой стороны поисковики не рекомендуют делать много уровней вложенности. Но о какой вложенности речь - о урловой или реальной? Реальная вложенность (по числу переходов) одинакова во всех вариантах.
Если бы структура было достаточно простой, то я бы наверно остановился на втором варианте, но у меня структура будет сложной, поэтому думаю было бы лучше полностью отразить ее в урле. Но пока колеблюсь.
Да, пробовал конечно, но тогда расход оперативки увеличивается в разы, особенно когда в 12 параллельных процессов на шести ядрах программу запускал. А у меня всего 32 гб оперативки.
