Всем привет.
На сервере два дисковых массива. Пропускная способность большая.
Есть много баз >100
Если смотреть через монитор ресурсов то можно увидеть что базы с которыми ни кто не работает в данный момент пишут логи и тем самым постоянно загружают харды на 100%
Фоновые/регламентные задания в этих базах отключены, модель востановления - Простая
Вопрос: как избавится от лишних телодвижений логов что бы разгрузить харды.
На сервере два дисковых массива. Пропускная способность большая.
Есть много баз >100
Если смотреть через монитор ресурсов то можно увидеть что базы с которыми ни кто не работает в данный момент пишут логи и тем самым постоянно загружают харды на 100%
Фоновые/регламентные задания в этих базах отключены, модель востановления - Простая
Вопрос: как избавится от лишних телодвижений логов что бы разгрузить харды.
По теме из базы знаний
- Практика перехода на Linux и Postgres в небольшой компании (10 пользователей)
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST
- Масштабирование 1С в облачной среде
- Переносим все логи в журнал регистрации – реально ли и зачем?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Логичный вопрос - какие именно лишние телодвижения отражаются в логах (причем полностью нагружая диски), если по вашим словам лишних телодвижений в этих базах нет.
Получите ответ на этот вопрос - станет понятно, что с этим делать.
Получите ответ на этот вопрос - станет понятно, что с этим делать.
(5) Ujine1313,
У тебя вагон ОЗУ?
Так ты разберись с начало что пишет. Может у тебя не 1С пишет, а рег задания на SQL или ещё что то... может какие нибудь обмены логируются.
Может есть какая то настройка не писать сразу на хард а кидать в ОЗУ а потом скопом сливать на хард.
У тебя вагон ОЗУ?
Так ты разберись с начало что пишет. Может у тебя не 1С пишет, а рег задания на SQL или ещё что то... может какие нибудь обмены логируются.
(10) Ujine1313, Логирование это не излишнее обращение. На сколько помню это нормально для SQL. По этому логи и выносят на отдельный накопитель. Так как логи последовательно пишутся. Вот они на этот накопитель последовательно и записываются. Не мешая дискам где лежат сами базы.
(12) Ujine1313,
Нет. SQL там сам всё разрулит... выноси логи на отдельный хард. Который у тебя будет использоваться ТОЛЬКО под логи.
Теоретическая ситуация: перенесу логи на другой хард и хард с логами будет загружен на 100% не приведет ли это к тому же что и сейчас, что вся база будет тормозить?
Нет. SQL там сам всё разрулит... выноси логи на отдельный хард. Который у тебя будет использоваться ТОЛЬКО под логи.
(17) fzt,
Можно и отключить...
Где я работал ни разу не отключали... может есть смысл, может нет... не подскажу. Как с таковым с SQL не работаю... так только установить, настроить и тд.
Да и то по большей части админ у нас этим занимался.
ещё можно отключить логи :D большинство никогда по ним не откатывалось...
Можно и отключить...
Где я работал ни разу не отключали... может есть смысл, может нет... не подскажу. Как с таковым с SQL не работаю... так только установить, настроить и тд.
Да и то по большей части админ у нас этим занимался.
(22) ipoloskov, как-то Вы коллега однобоко информацию воспринимаете. Я говорю о том, что многим не хватит даже квалификации сделать откат. Им это и не нужно. Я бы отключил логи.
(24) herfis, где он это сказал?
Один под систему, второй под БД. По дефолту это так воспринимается.
Урезание лога не приведет к особому увеличению производительности (я в курсе что его совсем отключить нельзя). Нафига им лог если DBA нету?
UPD: увидел скриншот. У автора БД на диске системном. Это проблема.
(24) herfis, где он это сказал?
>На сервере два дисковых массива. Пропускная способность большая.
Один под систему, второй под БД. По дефолту это так воспринимается.
Урезание лога не приведет к особому увеличению производительности (я в курсе что его совсем отключить нельзя). Нафига им лог если DBA нету?
UPD: увидел скриншот. У автора БД на диске системном. Это проблема.
(25) fzt, Ну, если на то пошло, то автоудаление зафиксированных транзакций из логов у автора и так работает. Цитата - "модель востановления - Простая".
Просто формулировка "отключение логов" для этого - не просто неправильная. Она вредная, т.к. человеку не в теме формирует абсолютно превратное представление о ее сути.
Просто формулировка "отключение логов" для этого - не просто неправильная. Она вредная, т.к. человеку не в теме формирует абсолютно превратное представление о ее сути.
1. Логи в MSSQL отключить нельзя. Физически. Журналирование - неотъемлемая часть СУБД, обеспечивающая ее отказоустойчивость. Можно включить автоудаление зафиксированных транзакций из логов, но нагрузки на диски это никак не снизит.
2. Хоть в каждой книжке и рекомендуется вынос логов на отдельный хард при отсутствии рейда (для распараллеливания нагрузки), для меня вообще ни разу не факт, что источник тормозов в этой ситуации - запись логов.
ЗЫ. У чела база лежит на том же харде, что и система. А вы ему про отдельный хард на логи и tempdb рассказываете.
2. Хоть в каждой книжке и рекомендуется вынос логов на отдельный хард при отсутствии рейда (для распараллеливания нагрузки), для меня вообще ни разу не факт, что источник тормозов в этой ситуации - запись логов.
ЗЫ. У чела база лежит на том же харде, что и система. А вы ему про отдельный хард на логи и tempdb рассказываете.
На сервере. 6 хардов.
С: - 2HDD RAID 10
D: - 1 HDD
E: - 1 HDD
F: - 2HDD RAID 10
Постепенно базы перекидываю с С: на F: логи на E:
Все базы не кидаю сразу с С: на F: потому, что С: будет не до нагружен а F: перегружен.
Сейчас думы на счет того покупать серверный SSD или брать еще два HDD в массив.
Ну и надо решить что делать с нагрузкой что бы не было лишних записей в логи и не нагружались HDD или хотя бы как то раздать приоритет по базам в которых работают всех чаще (программно, не вынося их на отдельные харды)
Так же сейчас иду по всем база через консоль кластера и ставлю блокировку регламентных заданий (до этого отрубал их в базах отдельно - типа полнотекстового поиска, извленчения текста и пр.)
С: - 2HDD RAID 10
D: - 1 HDD
E: - 1 HDD
F: - 2HDD RAID 10
Постепенно базы перекидываю с С: на F: логи на E:
Все базы не кидаю сразу с С: на F: потому, что С: будет не до нагружен а F: перегружен.
Сейчас думы на счет того покупать серверный SSD или брать еще два HDD в массив.
Ну и надо решить что делать с нагрузкой что бы не было лишних записей в логи и не нагружались HDD или хотя бы как то раздать приоритет по базам в которых работают всех чаще (программно, не вынося их на отдельные харды)
Так же сейчас иду по всем база через консоль кластера и ставлю блокировку регламентных заданий (до этого отрубал их в базах отдельно - типа полнотекстового поиска, извленчения текста и пр.)
(32) Ujine1313,
если модель восстановления у баз стоит простая, то в принципе не сташно разместить логи и данные на одном быстром массиве - R1. Если будет затык, то тогда уже надо дальше проектировать дискову подсистему
tempdb - Любит одиночество :)).
Но SSD я беру серверные (дорогие)
если модель восстановления у баз стоит простая, то в принципе не сташно разместить логи и данные на одном быстром массиве - R1. Если будет затык, то тогда уже надо дальше проектировать дискову подсистему
tempdb - Любит одиночество :)).
Но SSD я беру серверные (дорогие)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот