axa 3.0 клинит по страшному

[lev]

Цитата:

3) При приеме проиходит проверка наличия материала и создание ProdJournalTable i Line .

А проверяли сколько выполняется проверка наличия, а сколько создание журнала? что из них тормозит?

[dim123]

Цитата:

Сообщение от lev

А проверяли сколько выполняется проверка наличия, а сколько создание журнала? что из них тормозит?

да
все нормально работает отдельно
если их запускать отдельно никаких траблов


mazzy :

почему ? с использованием партии у нас растет инвентдим и сум по 30000 записей в месяц .
плюс инвентранс так как все движения с партей

[mazzy]

Цитата:

Сообщение от dim123

почему ? с использованием партии у нас растет инвентдим и сум по 30000 записей в месяц .
плюс инвентранс так как все движения с партей

1. Это плохо
2. Это не насколько плохо, поскольку со временем у вас партии должны закрыться (обнуляться). Как в количестве, так и в сумме. А inventsum имеет признак closed. По-умолчанию, стандартные классы выбирают только незакрытые записи из inventSum.

Вполне возможно, что у вас беда с индексами, поскольку закрытых записей стало много (относительно всего количества) и теперь старые индексы работают плохо.

В общем, барабашки нет.
Вам что советуют: локализуйте проблему, поймите ее. И прините ОСОЗНАННОЕ решение.

[dim123]

Цитата:

Сообщение от mazzy

1. Это плохо
2. Это не насколько плохо, поскольку со временем у вас партии должны закрыться (обнуляться). Как в количестве, так и в сумме. А inventsum имеет признак closed. По-умолчанию, стандартные классы выбирают только незакрытые записи из inventSum.

Вполне возможно, что у вас беда с индексами, поскольку закрытых записей стало много (относительно всего количества) и теперь старые индексы работают плохо.

В общем, барабашки нет.
Вам что советуют: локализуйте проблему, поймите ее. И прините ОСОЗНАННОЕ решение.

согласен . не закрытых 400 000 инвентсум .
инвенддим все равно будет расти . состояние скалда на какое то число будет использовать inventtrans i inventdim ? ето проблема


проблема стандарта останеца журнал инвентрура не создать меньще чем за 2 часа , надо менять стандарт ? согласны ?

проблема именно в логике ахапта , проверки происходят в цыкле

склоняюсь к тому :
1) ДБ на раид 1+0
2) инвентсум и дим отдельно на раид 1+0
3) инвенттранс отдельно на раид 1+0

или ето тожа глупо ?

компания маленкая но умудрились сделать с партиями такую лажу виновен партнер которий внедрял и посоветовал ето

[mazzy]

Цитата:

Сообщение от dim123

согласен . не закрытых 400 000 инвентсум .
инвенддим все равно будет расти . состояние скалда на какое то число будет использовать inventtrans i inventdim ? ето проблема

Тут еще важно соотношение между этими таблицами,
если количество записей в них примерно совпадает, то оптимизатору нечего делать.
если количество записей в одной отличается в разы/на порядки, то оптимизатор может начать выборку с маленькой таблицы.

Цитата:

Сообщение от dim123

проблема стандарта останеца журнал инвентрура не создать меньще чем за 2 часа , надо менять стандарт ? согласны ?

Наверное.

Насколько я помню (надо бы поглядеть), в трешке для каждой строчки журнала инвентаризации делался отдельный запрос на получение остатка.
В принципе, можно и нужно, чтобы при заполнении делался один запрос на остатки, а потом перебор строк в цикле.
Вроде в последних версиях починили... Надо в трешке глядеть.

Цитата:

Сообщение от dim123

склоняюсь к тому :
1) ДБ на раид 1+0
2) инвентсум и дим отдельно на раид 1+0
3) инвенттранс отдельно на раид 1+0

или ето тожа глупо ?

мысль правильная. Только она поднимет общую производительность, а не данную конкретную задачу.

[dim123]

Цитата:

Сообщение от mazzy

Тут еще важно соотношение между этими таблицами,
если количество записей в них примерно совпадает, то оптимизатору нечего делать.
если количество записей в одной отличается в разы/на порядки, то оптимизатор может начать выборку с маленькой таблицы.


Наверное.

Насколько я помню (надо бы поглядеть), в трешке для каждой строчки журнала инвентаризации делался отдельный запрос на получение остатка.
В принципе, можно и нужно, чтобы при заполнении делался один запрос на остатки, а потом перебор строк в цикле.
Вроде в последних версиях починили... Надо в трешке глядеть.


мысль правильная. Только она поднимет общую производительность, а не данную конкретную задачу.

нормальная рабочая ситуатция
1) в минуту 7 запросов на состояние склада
2) каждые 10 минут регистрация готовой продукции . т.е проверка наличия материалов плюс к этому
у нас рецептура не конкретная . т.е имеем Продукт Н1 . он состоит из компонента К1 и К2. каждые 10 минут принимая Н1 на склад проиходит
а) берем БОМ смотрим компоненты К1 и К2 , далее если компонента имеет подгруппу ПГ1. то берем все материалы с подгруппой ПГ1
находим их текущее количество на складе . Далее создаем журнал где используем вместо К1 все материалы ис подгруппы ПГ1 % их текущему количеству на складе.
3) склад в день принимает до 200 новых партий .
4) по всем складам движение с партией . порядка 200
5) продажи 200 партии

плюс ко всему запросы на состояние склада от юзеров , бугалтерия , счета , статистика .

все это как мне кажетца и убивает эти таблицы , диски не справляютца . вернее сказать время на чтение и запись .

[ViV]

Цитата:

Сообщение от dim123

все это как мне кажетца и убивает эти таблицы , диски не справляютца . вернее сказать время на чтение и запись .

Так посмотрите статистику на серверах - хотя бы дисковые очереди и загрузку памяти. Чтобы слова "кажетца" не было.

[lev]

Цитата:

Сообщение от dim123

да
все нормально работает отдельно
если их запускать отдельно никаких траблов

Вы меня немного неправильно поняли
Я предлагаю не отдельно запускать. А именно воссоздать ситуацию зависания!
Т.е. запустите создание ревизии, пускай работает... А в это время принимайте товар на склад, и ищите места где зависает!