MSSQL таблица Config (оптимизация работы 1С) #503494

Заметил, что при большой нагрузке SQL сервера 1с вылетает. Есть мысль, что вылет происходит при длительной блокировки к таблице Config. Причем блокировка выглядит как PAGEIOLATCH_SH (т.е. закрыто обращение к диску). А что если SQL запретить выгружать данную таблицу Config из памяти. Такое вообще возможно?

проверь

знать бы как ещё заставить скуль таблицу в памяти держать...

как-то так

ты бы, мил человек, сначала доказательства получил наличия взаимосвязи, а уж потом шашкой махал

ха, обработка для 1с7.7 )

кстати, "Данная функциональность была введена в целях улучшения производительности в SQL Server версии 6.5. DBCC PINTABLE имеет много крайне нежелательных побочных эффектов. Сюда входит потенциальное повреждение буферного пула. Инструкция DBCC PINTABLE не является необходимой, и была удалена для предотвращения дополнительных проблем. Синтаксис этой команды все еще работает, но не оказывает влияния на сервер." Это из 2005го

а вот счас буду запускать очередную обработку внутри скуля на 2 часа... должна показать результат )))

у тебя какой скуль-то?

2008r2. сча почитаю в хелповике...

тогда читай ...

заменена на отдых... pintable )

вот кто нибудь бы мне перевёл вот эту статейку

en-us  поменять на ru-ru слабо?

А зачем тебе это? Там ничего интересного

Блокировать страницы в памяти Этот параметр безопасности определяет, какие учетные записи могут использовать процессы для сохранения данных в физической памяти для предотвращения сброса этих данных в виртуальную память на диске. Применение этой привилегии может существенно повлиять на производительность системы, снижая объем доступной оперативной памяти (RAM). По умолчанию: нет.

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

в итоге виной всему окажется уставший витой шнурок...

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

да не, какой шнурок. извращаюсь над одним компом.

Вы как к такому выводу пришли? Как вы связали между собой ожидание PAGEIOLATCH_SH, таблицу конфиг и выдеты из 1С? Трассировка? dmv? Почему вы решили что это поможет?

может, начать с технологического журнала?

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

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

а сколько в пиковой нагрузке SQL оставляет ОЗУ для 1cv8.exe для потсроения ТД в миллион строк, мегабайт 100, не?

раз на одной машине все

ясно. pageiolatch_sh - это не блокировка. Гляньте на очередь к диску и процент активности диска, когда происходят вылеты - скорее всего там все очень плохо. activity monitor не показывает вам блокировки, он показывает ожидания (которые могут быть ожиданиями на блокировках). чтобы посмотреть кто и какие блокировки накладывает используйте sys.dm_tran_locks, в sys.dm_os_wait_stats показывает статистику ожиданий.

+ и мне все-таки непонятно как вы связали между собой pageiolatch и таблицу Config

усилием воли связал, я гарантирую это

Как же так? Что же делать?

ну запрос на config идет с ожиданием на этом самом pageiolatch_sh в мониторе промелькивает

1с включен пустой ))) сам скуль трудиться над запросом

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

(: так это.. activity monitor не показывает жеж сам запрос вроде.. Только тип - типа SELECT, INSERT... Можете скриншот выложить? Мне правда интересно. Да не важно - рабочая или нет. Посмотрите на диск. Скорее всего именно из-за него и отваливаетесь

+ кстати.. а ошибка-то какая? (:

есесно диск загружен, кто тут спорит... на картинке только видно запрос (но не к config'у...) тип ожидания там же в таблице видно

это проблема родилась еще в те времена, когда человечество не изобрело колесо, а  называется "жаба" дело в том, что если поместить в память конфиг, ожидание "наброситься" на следующую таблицу, т.е. вы конечно можете вместо одной таблицы на заклание духу блокировок бросить другую таблицу но жертва будет по любому лучший способ победить "жабу", наростить аппаратные ресурсы, в частности добавить дисков, и желательно SSD в PCI-Express

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

хочешь нарушить законы природы взять из ниоткуда? для того, чтобы где то что добавить, где то надо отнять "А что если SQL запретить выгружать данную таблицу Config из памяти. Такое вообще возможно?" дело в транзакциях, они все равно будут писаться у скуля одновременно пишется в один файл логов, зато про SIMPLE можно разбить на несколько файлов ndf и положить на разные диски если диск один, то не надо мучить задницу, особо ничего не измениться

Файлов логов может быть сколько угодно, но писАться всегда будет только в один. Когда он заполнится - в следующий и т.д. И это в любой модели восстановления. Единственный выход для ускорения записи логов - более быстрая дисковая подсистема. Если есть время, желание и лишний диск, можете попробовать создать новую файловую группу на свободном физическом диске и перенести туда наиболее активно используемую таблицу со всеми индексами (ту, в которую идет вставка). Правда потом эту файловую группу лучше удалить, а ее содержимое вернуть в PRIMARY.

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

"данные из логов" не попадают в файл данных. В файл данных данные попадают из памяти, по checkpoint'у, либо при проявлении активности lazy writer'a. Исключение - восстановление бд при запуске службы. С чем конкретно вы не согласны? И что имеете в виду под тем "как это сказывается на производительности записи в лог"? Собственно, лог потому и рекомендуют помещать на отдельный диск, чтобы случайные io, генерируемые в файле данных, не мешали последовательной записи в лог (ну или наоборот - чтобы запись в лог не мешала).

неуд, садитесь внимательно учим работу SIMPLE

Можете ссылку в BOL кинуть где утверждается обратное? В подтверждение своих слов могу вам предложить ознакомиться с главами: 1. "Запись страниц" (: Если какая-либо из страницы в буферном кэше изменилась, она не записывается сразу на диск, а помечается как грязная. Это означает, что до момента ее физической записи на диск к странице применялась одна или несколько операций логической записи. При каждой логической операции записи в кэш журнала, который записывает изменения, добавляется запись журнала транзакций. Записи журнала должны быть записаны на диск до того, как связанная с ними «грязная» страница будет удалена из буферного кэша и записана на диск. SQL Server использует метод, называемый упреждающим ведением журнала, который предотвращает запись «грязных» страниц до записи на диск связанных с ними логических записей. Это особенно важно для правильной работы диспетчера восстановления. ... «Грязная» страница записывается на диск одним из трех способов. Отложенная запись Активная запись 2. "Контрольные точки и активная часть журнала" ( При достижении контрольных точек измененные страницы данных записываются из буферного кэша текущей базы данных на диск. Это сводит к минимуму активную часть журнала, которую приходится обрабатывать при полном восстановлении базы данных. Во время полного восстановления базы данных выполняются следующие действия. 3. "CHECKPOINT" ( Записывает все «грязные» страницы в текущей базе данных на диск. «Грязными» страницами являются страницы данных, введенные в буферный кэш и измененные, но еще не записанные на диск. Контрольные точки экономят время во время последующего восстановления при помощи создания точки, в которой все «грязные» страницы гарантированно записываются на диск. Мне непонятно почему вы решили, что из лога могут читаться данные (кроме того случая который я описал).

попытки защитить свою позицию аппелируя к документации забавны. Где я сказал, что данные читаются из лога. Я говорил, о попадании данных в файл данных. Короче, включайте simple, проведите несколько объемных транзацкий и посмотрите, вырастит ли лог после завершения транзакций на объем в транзакциях. Удивитесь (если конечно слишком большой шаг прироста лога не поставите, тогда еще придется смотреть фактическое использование места внутри лога или шринковать), но данные "сбегут" в mdf (или если файлов несколько то в ndf тоже). Лан, не надо просто без практики учить жизни. )))

там есть пример как проверить поведение

Я вас не учу жизни, да и практики мне хватает.. Документация используется для подтверждения своих слов, а вовсе не для "защиты позиции". >>а в какой момент данные из логов попадают в файл данных именно это я понял как "данные читаются из лога". Вот эта ваша фраза ставит в тупик: Удивитесь (если конечно слишком большой шаг прироста лога не поставите, тогда еще придется смотреть фактическое использование места внутри лога или шринковать), но данные "сбегут" в mdf Вчеслав, данные не "сбегают" в mdf.. В простой модели восстановления после чекпойнта (т.е. после того как грязные страницы сброшены на диск) место, занимаемое зафиксированными транзакциями в журнале транзакций, помечается как неиспользуемое и журнал будет циклически перезаписываться. Если вы под "данные из логов попадают в файл данных" имеете в виду именно процесс усечения журнала транзакций - тогда мне более менее понятна ваша точка зрения, но с формулировкой я категорически не согласен - для этого процесса уже есть общепринятое название - и это "усечение журнала транзакций". Но его влияние на производительность довольно спорно, поскольку усекается журнал транзакций, ЕМНИП, по виртуальным файлам журнала, которых не так много.

Пример, к сожалению, не могу запустить, но понимаю что будет происходить. Могу предложить Вам самому провести эксперимент. Перед тем как запускать обработку, активно изменяющую данные, попробуйте подключиться к этой базе через SSMS и выполнить что-то вроде этого: USE [database] DELETE FROM dbo._Acc1 (здесь должна быть не пустая таблица которая не изменяется в ходе работы Вашей обработки - delete не обязательно, главное, чтобы в базе изменилась хотя бы одна строка) Главное не фиксировать и не откатывать эту транзакцию. После этого попробуйте запустить свою обработку - Вы увидите как журнал транзакций растет, не смотря на модель восстановления симпл. После окончания работы обработки - попробуйте перезапустить службу SQL Server, в логе SQL Server'a (Management -> SQL Server Logs) вы увидите что-то вроде "1 transaction rolled back in database ...", причем транзакций rolled-forward быть не должно, т.е. все изменения сделанные Вашей обработкой уже попали в файлы данных.

спор теоретика и практика MS тоже утверждает, что якобы 32х битный экземпляр скуля занимает до 2 Gb оперативной памяти (и в документации у них написано :)))) ) ну и что, а на практике потолок 1.5 Gb с этим тоже можно спорить, но практике оно будет так в 32х битной среде. как и в случаи с производительностью модели восстановления симпл (я утверждаю, что работать будет быстрее из-за другого поведения на запись данных) пока мои клиенты голосуют за мои результаты по повышению производительности кошельком, вы можете тут сколько угодно не соглашаться с терминологией надеюсь получилось донести по-существу

ясно. Доводов нет - давите авторитетом. Особенно радует ваша уверенность в отсутствии у меня практики. Не хотите продолжать - не надо. Я точно так же могу сказать, что разницы между FULL и SIMPLE в плане производительности нет (точнее есть, но не на тех операциях, которые использует 1С в обычной работе). Я также могу предложить несколько вариантов почему у вас симпл работает быстрее чем фулл, но вы это, похоже, обсуждать не намерены. Ок. Счастья вам и побольше клиентов (в этой фразе нет сарказма или иронии). Спасибо за Ваши статьи, среди них много действительно полезных и интересных.

дело не в доводах, быстро Вас не убедить, а долго не вижу смысла (мне это ничего ни в личном плане, ни в финансовом не прибавит)