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