Обсуждение и советы: создание интернет-магазинов - решения, процессы, прайсинг

Приходится вновь возвращаться к данному вопросу.
Первое что очень кидается в глаза так это то что основной процесс всегда занимает не более 512 ОЗУ, причем не важно 30 000 товаров или 90 000. Но при большой количестве товаров, просто нереальные числа чтения к жесткому диску, за день от этого процесса за ПЕТАбайты уходит. Программе явно не хватает озу, поэтому начинаются кучу "переливаний". Откуда это ограничение, можно ли поднять планку занимаемой озу?

2) сами операции. Проводим интересный эксперимент. Импортируем в базу прайс из всего одной позиции.. Импорт занимает более 5 минут! Что можно делать на xeone с полной загрузкой ядра более 5 минут? Отключаем некоторые прайсы в стипп - все гораздо быстрее! Честно не очень понятно, почему на время операции с одним прайс-листом очень влияют другие прайсы. Возможно причина та же - "переливание оперативки"

3) Когда сделали - не обновлять СТУС при добавлении товара - заметно улучшило комфорт работы в программе. Но очень не удобно, то что при открытии категории, происходят заново сравнения товаров. При импорте прайсов, все уже произошло, зачем при открытии категории это происходит заново? Лучше это сделать по отдельной кнопке.

По первому пункту, для вас доступна новая версия ПЛИ, проверьте на этой версии потребление оперативной памяти.
По остальным пунктам нужно время для тщательной проверки.

Протестировал.. Улучшение скорости заметно даже на "глаз". Основной процесс занял более 1 гб озу, но обращение к жесткому диску значительно меньше, и упала немного нагрузка на CPU
Но на скорость импорта прайса все равно влияет сколько активно других прайсов. Больше всего занимает операция : Добавляем /удаляем позиции из прайс листа. (8.5 минут, при 87000 товаров в стипп)

Так же обратил внимание на показатели процессов etrade_multi_thread. Во время импорта прайса в 4 мб, суммарная запись от этих процессов была 200мб, а вот чтение - более 17 гб, при этом объем занимаемой озу был в пределах 32 мб. Похоже тоже не хватает озу, что и вызывает излишние чтения.

Пакетная обработка так же стала быстрее.

Продолжил эксперименты и наблюдения.
Вижу после обновления стали создаваться по несколько процессов основной программы, multi_tread вообще не используется.
Запускаем обновления. 3 прайс-листа по 15-20 000 позиций каждый. Нагрузка на ядра не большие 3-6%, но записей и чтений очень много. Каждый процесс за обновления прайсов сделал более 4 млн обращений на запись и чтение, и каждый прочитал более 20 гб! информации. Наблюдая за файлами - supply_products.FPT и supply_products.dbf постоянно меняют размер. Получается все операции сразу записываются.
Может лучше сделать всю обработку в озу, а потом записать файл уже на носитель? Конечно для этого придется заблокировать импорты под другими пользователя. Но как-то весьма малопрактично чтоб запускали импорт сразу разные пользователи. Да и оборудования от таких записей сейчас весьма изнашивается.
Интересно, когда остался всего один фаил, процессор сразу стал нагружен на 12.5% (все ядро). Значит запись/чтения является слабым местом.