<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Для 8-ки встречал вот такое:http://www.gilev.ru/1c/81/lock/index.htm
to 1, эта для конкретной базы, а в САБЖ-е для сервера в целом (пофигу сколько и каких баз).
кроме того в САБЖЕ анализ шире, по сколько анализируеться на сами блокировки и не запросы а системные счетчики
Скрипт толком не рассматривал. Тут же дело в том, что 1С-ка не использует SQL, как положено… А так… В качестве хранилища данных… Но посмотреть стоит…
to 3
так в этом и весь прикол, этой ХП пофиг как работаешь, она показывает статистику, и на основании статистики можно оптимизировать не только саму 1с, но, что самое главное всю систему под РЕАЛЬНОЙ нагрузкой, учитывая и скорость работы клиентов и дисков и т.д.
Эта ХП позволяет найти слабые стороны САМОГО SQL СЕРВЕРА
А не могли бы сказать неискушенному в серверах, где бы можно посмотреть расшифровку полученного результата? Желательно на руссоком языке.
в гугл вбиваешь и читаешь,
ну если на английском, но у мелкомягких
Чесно говоря несколько не ясна поль за от такой статистики:
***total*** 3194903351.0 100.0
OLEDB 3175652096.0 99.4
Ну вижу я что OLEDB занимает 99% а дальше чего?
to 7
не то смотришь, или активности нету…
бывает всякая фигня, типа «PAGEIOLATCH_SH» и т.д.
запускать надо на рабочем сервере в рабочее время на длительноое время (я рекомендую 4-6 часов)
Решение оформлено не правильно. Надо обработочкой для 7.7 и 8.х с 1 кнопкой — исправить 😉
to 9
я не претендую на полное решения, я написал, что не мое и просил не плюсовать.
решение преднозначено для оптимизации SQL сервера, а не конкретных баз, по этому я считаю, что все нормально.
а про 1 кнопку — это только вред, интересно, что будет делать тупой пользователь с результатами? да и права SA нужны
to 6
http://www.sqldev.net/misc/waittypes.htm
нашел тут
to 11
спасибо, то, что нужно
to 8 вообще то сервер самый что ни на есть рабочий и пользователей штук 50 на нем есть и замеры 5 часов делались.
(13) по ссылке в (11)
Сервер SQL ждет ответа клиента, чтобы послать данные
короче долгий отклик приложений, то есть он типа все сделал и ждет когда клиент заберет данные.
думаю все очень понятно!
to 14, ага спасибо уже почитал
to 15
вот так и понимаешь, что в тормозах сам скуль не виноват 🙂
напрягай админов, пусть это показатель сокращают до 10-20%
(0) НЕ МОЯ!!! просьба НЕ плюсовать
За такую фразу так и хочется плюсик влупить 🙂
я передумал, можете плюсовать 🙂
причина простая, теряеться она среди прочих пустых вещей, а ведь нужная вещь
Расшифровка результатов на русском и в более полном варианте
http://msdn.microsoft.com/ru-ru/library/ms179984.aspx
добавил картинку (что-бы народ понимал, что за фиговина такая)
(2) функциональнось полностью перекрывается обработкой из (1)
если думаешь, что не так, то смотри код обработки 🙂
(21) обработка в (1) хороша инужна, но по моему это разные вещи
1. если у огранизации совсем нету 8.1 ????
2. если административные установки не позволяют пользоваться SWbemLocator
————следующие пункты ИХМО (могу заблуждаться)—————
3. реализованы далеко не все виды счетчиков
4. как я понял в (1) результаты счетчиков выводяться для конкретной базы («SELECT * FROM «+БазаДанных+».dbo.View_Lock_W») а в САБЖе для сервера в целом
(22) рекомендую другие закладки посмотреть, прежде продолжим обсуждение
в настоящее время обработка развивается «в закрытом» режиме, например умеет находить и строить отсутствующие индексы в субд
А под IBM DB2 будет работать?
(25) пока на практике таких заказчиков не было, но если появяться, то почему нет
вот чего-то не допонял…
из QA: CXPACKET 949831.0 53.2
«CXPACKET
Имеет место при попытке синхронизации итератора обмена обработчика запросов. Можно попытаться снизить степень параллелизма, если конфликты такого типа становятся проблемой.»
это шо за ?
а этого: NETWORKIO 96863.0 5.4
вообще в табле не нашел (((
CXPACKET
Имеет место при попытке синхронизации итератора обмена обработчика запросов. Можно попытаться снизить степень параллелизма, если конфликты такого типа становятся проблемой.»
это шо за ?
в настройках SQL в свойствах параллелизма ставь 1 (а у тебя скорее всего там 0)
NETWORKIO — ожидание клиента
(28) нашел:
«CXPACKET
Parallel process waits. Possible skew of data possible lock of a range for this CPU, meaning that one parallel process is behind, etc.
Check for parallelism using sp_configure ‘max degree of parallelism’.
If max degree of parallelism = 0, you may want to do one of the following:
· Turn off parallelism by setting max degree of parallelism to 1
· Limit parallelism by setting max degree of parallelism to less than the total number of CPUs. For example, if you have 8 procedures, set max degree of parallelism to 4 or less.»
стоял действительно 0 )))
поставил на 4 пока — потестю )))
спасип )))
ЗЫ поставил на 4 потому как CPUs 2*4core )))
(30) включи поддержку 4х ядер, но параллелизм ставь 1
вот теперь таки выползло:
NETWORKIO 9577.0 85.8
из SQLDEV.NET:
«NETWORKIO
Waiting on network I/O completion. Waiting to read or write to a client on the network.
This can occur if a client is in the middle of sending packets to SQL Server, or when SQL writes data to a client and is waiting for an ACK.
Check bandwidth of your network interface card. 100 mbits is preferable to 10 mbs.»
а откуда оно если и 1С и скуль на 1 машине в терминале?
(1)
а она фунциклирует если нет сервера предприятия 8???
к скуль-серверу подключается, а при попытке «подготовить к мониторингу»
Форма.Форма(388)}: Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near ‘(‘.
RecSet.Open(Query,SQLServer,3,1,1);
по причине:
Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near ‘(‘.
(32) вот теперь вы видишь, что или сама сеть или клиенты тормозят. Админов напряги пусть уменьшают до 5%
(32) у тебя SQL и терминал на ОДНОЙ???
какие настройки сервера ? на службы или на приложения?
вообще на 1 машине их НЕЛЬЗЯ ставить
(34) концовку пропустил:
«а откуда оно если и 1С и скуль на 1 машине в терминале?»
(35) угу — на 1й ((((((((((((( на вторую денех не дають )))
по поводу «нельзя ставить»: если очень нужно, то можно )))) выхода то нету )))
настройки и проц и память на приложения…
у тебя вероятно на терминал памяти не хватает, ограничивай скуль, и в сесиях смотри кто сколько жрет… патч от ромикса поставь на 100% загрузку, дальше будет видно.
запусти виндовые счетчики… короче нужно
1. уменьшить по максимуму все в сесиях, почту/аськи/офис/интернет — все в топку
2. пытаться сбалансировать распределение ресурсов
кто-нибудь знает какое желаемое распределение процентов по задержкам должно быть (ведь уменьшая простои по одному типу будут расти простои по другим типам) ?
(39) во первых уменьшая одно у тебя должно уменьшаться Total
во вторых все должно упираться в дисковые операции и они должны быть более менее симетричными (например write-25% writeLog-30%, остальное частями не более 10%),
это конечно мое личное мнение, кто-то считает по другому, но я считаю раз HDD самая медленая деталь в компе, то упираться должно в нее…
можно конечно пытаться упереться в загрузку CP, но при современных многоядерных серверах это не реально 🙂
(40) Выполнил тестирование на продуктовых серверах.
Вот результаты:
Сервер 1 — Одна 10G база под сайт (1Gbit канал с веб-сервером, трафик не более 800 kBit/s)
***total*** 1653620.0 100.0
OLEDB 546265.0 33.0
LAZYWRITER_SLEEP 540000.0 32.7
SQLTRACE_BUFFER_FLUSH 540000.0 32.7
SLEEP_TASK 14640.0 .9
CXPACKET 5484.0 .3
LCK_M_IS 2781.0 .2
SOS_SCHEDULER_YIELD 1000.0 .1
MSSEARCH 1250.0 .1
MSQL_DQ 859.0 .1
Сервер 2 — 10 сателитных баз (от 1G до 10G)
***total*** 2760902.0 100.0
CXPACKET 974218.0 35.3
PAGELATCH_EX 593562.0 21.5
LAZYWRITER_SLEEP 541000.0 19.6
SQLTRACE_BUFFER_FLUSH 540000.0 19.6
EXECSYNC 82468.0 3.0
LCK_M_IX 28531.0 1.0
Верны ли следующие выводы:
1) производительность сервера 1 притормаживается web-сервером.
2) оптимизировать запросы на втором сервере:
— искать запросы с параллельнымми планами выполнения
по 1 серверу:
LAZYWRITER_SLEEP, SQLTRACE_BUFFER_FLUSH — это трассировки и прочие средства отладки, на рабочей базе их надо отключать на время когда они не нужны
OLEDB — это уже от веб сервера, на нем нужно сократить транкзации, как я не знаю (надо смотреть всю систему в целом).
по 2 серверу
CXPACKET — поставить параллелизм в 1
PAGELATCH_EX — это от кода зависит, вероятно какието ручные блокировки
ну и отладку SQL отключить
(42) спасибо. будем пробовать
Подскажи пожалуйста в ссылках ничего толкового не нашел
Сервер 3 базы 2 по 8 ГБ 1по 1 ГБ
Оперативки 8 ГБ
4 процессора по 2ГГрца
но 1ска УТ все равно тормозит и ругается на транзакции
статистика обновляется раз в 4 часа и реидексация стоит еженощно
MISCELLANEOUS; 17950296.0; 30.9
LAZYWRITER_SLEEP; 17948828.0; 30.9
SQLTRACE_BUFFER_FLUSH; 17912500.0; 30.8
LCK_M_IS; 1553453.0; 2.7
LCK_M_IX; 711812.0; 1.2
SLEEP_BPOOL_FLUSH; 425031.0; 0.7
конкретно что такое MISCELLANEOUS; 17950296.0; 30.9
(45) я не знаю, у тебя какой сервер? (ведь не 2000!) ищи в MSDM на сайте мелкомягких.
Могу только предположить, что это какие-то теневые операции скуля (тригеры, репликации с другой базой и т.д.)
спасибо буду искать)
Имеем 1С-базу 30 Гб, 25-30 активных пользователей, связку терминального и SQL-сервера по гигабитной сети. Конфа SQL-сервера: PentiumD 3,4 GHz, 4 GB RAM, массив RAID5 на контроллере Adaptec 2130S из 5 дисков SCSI 10 000RPM Fujitsu. Используем SQL 2005 WorkGroup Edition. Всё это добро в последнее воемя тормозит, блокировки журнала очень часто (по 5-10 секунд).
Делал замер производительности по счётчикам винды: загрузка проца средняя 60%, в пиковые моменты — 100. Средняя длина очереди диска — 200 (максимальная больше 1000), в основном очередь на запись, счётчик очереди по чтению поменьше. SQL использует 3 гига памяти
Делал замеры, помогите интерпретировать результаты:
wait type; wait time; percentage;
LAZYWRITER_SLEEP; 3545453.0; 63.1;
CXPACKET; 947578.0; 16.9;
IO_COMPLETION; 286500.0; 5.1;
PAGEIOLATCH_SH; 267906.0; 4.8;
SLEEP_TASK; 193000.0; 3.4;
WRITELOG; 130750.0; 2.3;
LCK_M_X; 77234.0; 1.4;
SOS_SCHEDULER_YIELD; 64703.0; 1.2;
PAGEIOLATCH_EX; 59687.0; 1.1;
LAZYWRITER_SLEEP —
Имеет место при приостановке задач средства отложенной записи. Представляет собой показатель времени, затраченного ожидающими фоновыми задачами. Не следует учитывать это состояние при исследовании пользовательских простоев.
на сколько я понимаю затык в кеше, вероятно просто памяти не хватает для внутреннего кеша и он вытесняет его в своп (а своп медленный и системный), попробуй включить поддержку 4х гигов памяти, если сожрет 4 гига, значит я прав.
обычно это бывает из-за бешеного количества «мелких» запросов, например вычисляемая колонка в справочнике
кстати, то, что у тебя загрузка ЦП доходит до 100 — то же не гуд, скуль не должен жрать больше 70-80% в пиках
У нас SQL WorkGroup — он больше 3 гиг кушать не умеет =/
Может какие-то скульные счётчики посмотреть чтоб с кэшем удостовериться? Пока грешу на RAID5, т.к. очередь на запись скачет, а он по записи тормозной. Ну и проц бы поменять, думаю.
(51) скульных счетчиков нету для этого, копай виндовые для обмена память<->своп
думаю можно посмотреть профайлером в момент пиковой загрузки (просто количество запросов в 1 сек) если их много — то см. (49)
Уважаемый гуру, подскажи!
по тестам из (0) большего всего занимает WRITELOG (от 32 до 45%), на втором месте LCK_M_X (до 30%) — дальше все по мелочам…
Как оптимизировать? Куда смотреть?
База 7.7 25 релиз, SQL 2000 sp4. На сервере 8гб памяти (PAE + AWE), рейд 10 на Sata2 (на нем и база и лог). База <20Гб в режиме Simple.
WRITELOG — перенеси лог файл на другой ФИЗИЧЕСКИЙ диск, или райд более быстрый собирай, можно вообще лог отключить, потеряешь возможность востановление в течения дня, зато работать будет быстрее
(54) Я так понимаю первый вариант предпочтительней, но на данный момент для меня не достижимый.
Буду отключать лог (тем более я понятия не имею как с помощью лога что-либо восстанавливать да и бекап ежедневно делаю).
Большое спасибо за совет.
зедсь уже писали что возникла такая ошибка :
к скуль-серверу подключается, а при попытке «подготовить к мониторингу»
Форма.Форма(388)}: Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near ‘(‘.
RecSet.Open(Query,SQLServer,3,1,1);
по причине:
Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Line 7: Incorrect syntax near ‘(‘.
такая же беда… В чем может быть дело ?
PAGEIOLATCH_EX
Имеет место, когда задача ожидает кратковременной блокировки буфера, находящегося в состоянии запроса ввода-вывода. Запрос на кратковременную блокировку производится в режиме общего доступа. Длительное время ожидания может указывать на проблемы с дисковой подсистемой.
,189171.0,.8 — это много?
del
А как этим скриптом пользоваться?
Попробовал собрал статиску, интересно. Но тормоза сервера были по другой причине
База 1с около 130 гб, скл, конфигурации серверов сейчас не могу сказать. за 2,5 часа получил вот такую статистику. Кто что может сказать по этому поводу?
***total*** 18538808.0 100.0
LCK_M_X 5368370.0 29.0
PAGEIOLATCH_SH 4199847.0 22.7
LCK_M_IS 3980967.0 21.5
LCK_M_U 3611659.0 19.5
WRITELOG 385871.0 2.1
CXPACKET 355302.0 1.9
PAGEIOLATCH_EX 336477.0 1.8
LCK_M_S 205544.0 1.1
Плюсик
(61) Zdec1,
в целом не так плохо
PAGEIOLATCH_SH — конечно великовата, копай в сторону размеров файловых буферов и их оптимизации
LCK_M_X, LCK_M_IS — весьма характерные блокировки для 7.7 и по моим наблюдения они зависят скорее не от SQL а от скорости каталога с MD и темпов, для SQL версии вообще разумно сделать для этого рам диск.
ИХМО
в конечном итоге самое слабое место SQL — скорость записи лога, WRITELOG должно быть от 10 до 30%
(63) спасибо, будем копать в эту сторону
Отличная штука, будем пробовать
(42)
«по 1 серверу:
LAZYWRITER_SLEEP, SQLTRACE_BUFFER_FLUSH — это трассировки и прочие средства отладки, на рабочей базе их надо отключать на время когда они не нужны»
А как отключить это дело ?
Вот результаты теста, куда смотреть ? где узкие места ? Подскажите, пожалуйста.
Тема активна ?
Не забывам комментарии удалять в скрипте, а то ругается:
Incorrect syntax near ‘/’.
Msg 102, Level 15, State 1, Line 4
Incorrect syntax near ‘/’.
Msg 111, Level 15, State 1, Line 14
‘CREATE/ALTER PROCEDURE’ must be the first statement in a query batch.
Cannot add rows to sys.sql_dependencies for the stored procedure because it depends on the missing table ‘get_waitstats’. The stored procedure will still be created; however, it cannot be successfully executed until the table exists.
Что-то не могу скачать скрипт. Премиум доступ оплатил.
Более полноценную картину бесплатно можно получить с помощьюhttp://www.gilev.ru/sqlsize/
Подскажите куда копать:
1С 7.70.027 для SQL
***total*** 213255969 100
XE_DISPATCHER_WAIT 57630092 27
CHECKPOINT_QUEUE 28606900 13,4
SQLTRACE_BUFFER_FLUSH 17944972 8,4
LAZYWRITER_SLEEP 17945744 8,4
LOGMGR_QUEUE 17885276 8,4
REQUEST_FOR_DEADLOCK_SEARCH 17945304 8,4
XE_TIMER_EVENT 17940060 8,4
FT_IFTS_SCHEDULER_IDLE_WAIT 17760364 8,3
SLEEP_TASK 8985282 4,2
BROKER_TO_FLUSH 8973495 4,2
LCK_M_IS 661023 0,3
CXPACKET 443392 0,2
SLEEP_BPOOL_FLUSH 152757 0,1
IO_COMPLETION 137195 0,1
сервер покупался в январе 2012г:
Windows Server 2008R2 Hyper-V
MB Intel S5500BCR
CPU 2 x Intel Xeon E5607 (8 ядер)
RAM 8 x 2Gb = 16Gb
RAID controller = Intel SRCSASLS4I
RAID1 = 2 x Seagate 300Gb ST3300657SS 15000rpm SAS
сервер 1С: виртуальная машина №3
Windows Server 2008R2
CPU 4 ядра
RAM 8Gb
MS SQL 2008
база SQL: 8,1Гб
на данный момент железо наращивать не планируется.
Переход на 1С8 тоже не планируется как минимум год.
Проблема: при переключении окон часто появляется белый экран и висит несколько минут.
виртуальная машина №2 — сервер управления антивирусом — загружен минимально
CPU 2 ядра
RAM 2Gb
виртуальная машина №1 — шлюз в интернет на Linux — загружен мало
CPU 2 ядра
RAM 1.5Gb
проблема с долгим откликом окон клиента скорее всего не связана с SQL напрямую, скорее тут дело в чем-то хитром, типа временного кеша, или разрывом сесий.
Симптомы похожи на то, что 1с ожидает ответ от SQL но не получает его, и тут главный вопрос — какие такие запросы 1с шлет в SQL при переключении окон, возможно там что-то левое тормозит …
высокий XE_DISPATCHER_WAIT можно попробовать побороть переводом SQL в режим однопоточности и одновременным включением ежедневного регламента обновления статистики. При этом и поиск дедлоков должен исчезнуть.
Более точно мне сложно сказать, потому как нормально подружить Ваш гипервизор и Ваш SQL — довольно нетривиальная задача, там куча специальных настроек нужна…
vde69, спасибо за быстрый ответ. Пока попробовал довести размер оперативки для 1С-виртуалки 8Gb -> 12Gb, с утра повторно запущу тест и затем выложу.
После добавления оперативки картина поменялась:
***total*** 143770908 100
XE_TIMER_EVENT 17970036 12,5
LOGMGR_QUEUE 17944784 12,5
REQUEST_FOR_DEADLOCK_SEARCH 17945260 12,5
CHECKPOINT_QUEUE 17908664 12,5
SQLTRACE_BUFFER_FLUSH 17941024 12,5
LAZYWRITER_SLEEP 17945052 12,5
FT_IFTS_SCHEDULER_IDLE_WAIT 17760338 12,4
SLEEP_TASK 8975681 6,2
BROKER_TO_FLUSH 8972515 6,2
CXPACKET 86349 0,1
PAGEIOLATCH_SH 136859 0,1
После завершения теста занято оперативной памяти всего 6Гб.
еще раз спрошу
1. какими средствами дружили 1с и скуль ?
2.. на скуле включен параллелизм=1 ???
1. Не владею навыками настройки, SQL 2008 ставился по умолчанию на ту же машину с RDP. Перенос базы делал программист 1С.
2.
«Максимальная степень параллелизма» попробовать поставить единичку и повторить тесты?
(77) scherbinin,
ставь 1,
настрой обновление статистики в SQL раз в 4 часа, (ОБЯЗАТЕЛЬНО)
дай поработать сутки,
потом уже повторяй тест
Вот тут статья есть по расшифровкеhttps://habrahabr.ru/post/216309/
Я бы помог