Производительность

[Def]

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

уточнения, забыл про второй выделнный файл итого

1. база 550Гб без лога
2. таблицы inventtrans, prodbom, имеют Page Compression
2. index hint до перехода на sql2008 были выключены счас пришлось включить
3. снимаем стаитстику смотрим добавлеям хинты в код или реорганизуем существующие у таблиц (не нравится мне это)
4. 4 аоса с балансировкой
5. recovery model FULL
6. кто нибудь практикует свертку inventtrans ledgertrans за далекие периоды (счвертка в прмяом смысле слова с заменой на к примеру журналы проводка который ставит остаток на начало какого то периода)
7. скрин Disk Usage by Table приложу не могу здоровая pdf не лезет во вложение

Спасибо fed за конкретизацию мысли я об этом догадывался но никак не мог формализовать в словоформе, я не сторонник прописывания в запросы индехов ибо индехи создаю на этапе создания таблицы и продумываю какие выборки будут по этой таблице производится, по этой причине никогда не углублялся в познание SQL статистики, профан.

[Zabr]

Цитата:

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

база 550Гб без лога

Можно пару вопросов?
1) Сколько лет работает Аксапта?
2) Почему при 100 пользователях у вас аж 4 АОСа ? по-моему, это много. В какой момент ставили 2-й, 3-й, 4-ай АОСы, то есть по какому критерию определяли, что их пора добавлять? у нас на 110 одновременных пользователей - 2 АОСа, и рассчитываю что их хватит до 160-180 пользователей.

[gl00mie]

Цитата:

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

начиная с версии SQL 2005, SQL использует так называемый parameter sniffing. Чего в такой ситуации делать:

Можно еще поставить обновление на Ms SQL 2008 и отключить parameter sniffing, см. axperf: Important SQL Server Change! - Parameter Sniffing and Query Plan Caching

Цитата:

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

скрин Disk Usage by Table приложу не могу здоровая pdf не лезет во вложение

Не надо здоровый pdf - есть скрипт, который выдаст обычный текстовый отчет, из которого можно показать тут какой-нить top 20 таблиц.

Цитата:

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

Почему при 100 пользователях у вас аж 4 АОСа?

На самом деле, пользователи - ленивы и не любопытны медлительны и редко когда могут загрузить АОС и СУБД так, как их может загрузить какой-нить пакетник сопоставления или обмен с внешней системой, накидывающей заказы пачками. Так что, может, там основную нагрузку вовсе и не пользователи создают.

[Def]

Цитата:

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

Можно пару вопросов?
1) Сколько лет работает Аксапта?
2) Почему при 100 пользователях у вас аж 4 АОСа ? по-моему, это много. В какой момент ставили 2-й, 3-й, 4-ай АОСы, то есть по какому критерию определяли, что их пора добавлять? у нас на 110 одновременных пользователей - 2 АОСа, и рассчитываю что их хватит до 160-180 пользователей.

рабоатет с 2005 года
лицензий 300 на них и расчитывали 4 аоса
просто временно работает вместо 300 чел 100 чел
действительно оснвная нагрузка создается пакетниками которые и делают основную тяжелую работу по производству по планированию по разноске

table_name row_count table_size data_space_used idx_space_used unused_space
INVENTTRANS 63858530 150592936 24709000 110640000 15243936
LEDGERTRANS 17039073 93479104 37290672 52150808 4037624
PRODJOURNALBOM 33219296 27138360 20507392 6592104 38864
PURCHLINE 4784237 12069224 8190040 3814552 64632
INVENTJOURNALTRANS 12431286 11841728 8399032 3384528 58168
PRODCALCTRANS 13963100 9336000 6312288 2995680 28032
BOMCALCTRANS 10659228 6583264 5975584 587320 20360
PRODBOM 10819244 6549064 1123304 5272120 153640
VENDINVOICETRANS 3982171 6132728 5100112 1019912 12704
INVENTSUMDATETRANS 9546332 3549528 3472680 72408 4440
INVENTREPORTDIMHISTORY 20401593 2648248 2575952 54744 17552
INVENTJOURNALTABLE 2566915 2301200 1570640 709320 21240
SYSTRACETABLESQL 492340 2257232 2253984 2608 640
INVENTDIM 3214504 1770592 422072 1347152 1368
PRODTABLE 803396 1756224 1074032 621408 60784
PRODJOURNALTABLE 2944891 1714992 1139464 566176 9352
INVENTSUM 3195279 1543904 1119256 424008 640
PRODJOURNALPROD 2090276 1456568 942600 502472 11496
PRODTABLEJOUR 3217955 1398800 701936 689488 7376
XREFREFERENCES 4438386 989304 374536 614128 640
PURCHLINEDELETE 377676 715408 606368 84848 24192
VENDPACKINGSLIPTRANS 883102 700968 542792 157880 296
TRANSACTIONLOG 2660296 428160 419936 3728 4496
SYSTRACETABLESQLEXECPLAN 476423 412640 410992 440 1208
BOM 153860 395072 263576 121872 9624
INVENTTABLE 61808 336824 176896 143600 16328
SALESLINE 139124 300176 192080 96504 11592
INVENTJOURNALREPORTTABLE_RU 973543 296608 125296 165080 6232
PRICEDISCTABLE 174663 274032 110912 158888 4232
LEDGERSUMTMP 826345 263712 211688 49328 2696
ADDRESSZIPCODE 547995 240416 104448 135648 320
CUSTINVOICETRANS 140238 220648 179688 36360 4600
VENDINVOICEJOUR 133588 216816 156600 51584 8632
PRINTJOBPAGES 86448 199120 191328 4408 3384
JOURNALERROR 100128 188960 161456 9832 17672
INVENTTABLEMODULE 370884 185504 181720 2344 1440
SYSUSERLOG 586620 183704 72400 107952 3352
XREFPATHS 413452 175864 104856 70448 560

[kornix]

добрый день!
Насколько я помню AOS 4-ки не может утилизировать больше 2Гб памяти (связано видимо с особенностями реализации). По идее, узкие места по производительности можно выявить с помощью нагрузочного тестирования.. Можно попробовать взять стандартный AxBenchMark, немного изменить под себя и запустить. Процесс интересный, полезный, графики и отчеты красивые получаются
Проект можно взять здесь

[mazzy]

Цитата:

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

table_name row_count table_size data_space_used idx_space_used unused_space
INVENTTRANS
LEDGERTRANS
PRODJOURNALBOM
PURCHLINE
INVENTJOURNALTRANS
PRODCALCTRANS
BOMCALCTRANS
PRODBOM
VENDINVOICETRANS
INVENTSUMDATETRANS
INVENTREPORTDIMHISTORY
INVENTJOURNALTABLE
SYSTRACETABLESQL
INVENTDIM
PRODTABLE
PRODJOURNALTABLE
INVENTSUM
PRODJOURNALPROD
PRODTABLEJOUR
XREFREFERENCES
PURCHLINEDELETE
VENDPACKINGSLIPTRANS
TRANSACTIONLOG
SYSTRACETABLESQLEXECPLAN
...
SYSUSERLOG
XREFPATHS

ну... особо лишнего у вас в базе нет.
можно безболезненно почистить systracelog и SYSUSERLOG
также скорее всего можно удалить удаленные закзаы типа (PURCHLINEDELETE)

дальше нужно смотреть на ваше приложение.
но в стандартном приложении все журналы/заказы - черновики (ищите на форуме обсуждалось неоднократно)
черновики в стандартном приложении можно удалять.
но журналы нельзя удалять в локализованном приложении с запущенной книгой продаж и покупок, а также если у вас "странно" написаны отчеты.

но в целом - вполне правильное распределение таблиц.

немного странно, что у вас в этом списке нет inventSettlement.
у вас, скорее всего, сильно переписано закрытие или вы его не используете.
(обычно в InventSettlement можно абсолютно безболезненно удалять записи, у которых cancelled = Yes)

[mazzy]

Цитата:

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

table_name row_count table_size data_space_used idx_space_used unused_space
INVENTTRANS 63858530 150592936 24709000 110640000 15243936
LEDGERTRANS 17039073 93479104 37290672 52150808 4037624

кстати, если загрузить ваши данные и проанализировать.
то сразу видно, что у LedgerTrans и InventTrans (особенно у InventTrans) индексы занимают гораздо большее место, чем сами данные.

Это значит, что, скорее всего, на поддержку индексов система тратит неадекватно большое время (при записи и обновлении). А к trans таблицам обновление/добавление применяется очень часто.

кроме того, судя по тому, что у InventTrans неиспользуемое место почти сравнялось с местом под данные, можно сделать предположение, что вы давно не проводили реорганизацию данных в SQL. следовательно, скорее всего, данные сильно фрагментированы. Следовательно, SQL выполняет гораздо больше операций чтения/записи с диском.

Скорее всего, стоит еще раз подумать над индексами (особенно у InventTrans)
и провести реорганизацию данных (хотя бы один раз)