Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
Статистика использования сетевых ресурсов показывает, что пропускная ширина используется на 1-3% (сервера стоят в разных шкафах но воткнуты в один свич), количество пакетов при этом тоже сильно не возрастает. Отключаем репликацию - все ОК. Репликация и пользователи работают по одному и тому же сетевому интерфейсу. Я пониая это так - сервер не успевает посылать буфера на вторичный сервер, на вторичном сервер вроде бы как нагрузки при этом большой нет - а может не туда смотрел. При асинхронной репликации сервер вроде бы как должен послать буфер на реплику и сразу же освободиться, подробное описание этого момента я не нашел, либо не так понял. Есть ли у кого какие идеи для решения данной проблемы? Варианты с отдельным сетевым интерфейсом для репликации и перевод БД в BUF пока не рассматриваем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 19:48 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
ну, попробовать асинхронную, для начала... В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 20:10 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
Железо вторичного сервака такое же, как и первого ? Дисковый массив, случаем, не совместный ? ДНС настроен ? Проблемы в сети (задержки при доступе ко вторичному серверу) не возникают ? ОС какие ? Версии IDS какие ? На каких операциях первичного сервера возникают задержки и насколько значительные ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 22:16 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
Прошу прощения. Долго писал - меня какого-то вышибло с форума, а потом с буфера скопировал не то (начало пропустил) - пятница ж была. Информикс - 9.40 ОС - Sun Solaris Железо - разное. Приложения работают на сервере, где расположен первичный сервер - скажем так - в той же среде, доменов и т.п. не используем. Параметры репликации: DRINTERVAL 30 DRTIMEOUT 10 Репликация сама по себе работает нормально - проблем вроде не замечали. Возникла ситуация, когда понадобилось перенаправить часть запросов на вторичный сервер, чтобы чуток разгрузить первичный. Перенаправили. Здесь возникли тормоза - со вторичным сервером все работает нормально, но на первичном сервере начались жуткие тормоза. Посмотрели - нити находятся в ожидании освобождения буфера лог журналв, отключили реплиацию - все ОК. Репликация и пользователи работают по одному и тому же сетевому интерфейсу. Я пониая это так - сервер не успевает посылать буфера на вторичный сервер, на вторичном сервер вроде бы как нагрузки при этом большой нет - а может не туда смотрел. При асинхронной репликации сервер вроде бы как должен послать буфер на реплику и сразу же освободиться, подробное описание этого момента я не нашел, либо не так понял. ДНС используется. Есть ли у кого какие идеи для решения данной проблемы? Варианты с отдельным сетевым интерфейсом для репликации и перевод БД в BUF пока не рассматриваем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2006, 18:16 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
Igor Zaiets Возникла ситуация, когда понадобилось перенаправить часть запросов на вторичный сервер, чтобы чуток разгрузить первичный. Перенаправили. Здесь возникли тормоза - со вторичным сервером все работает нормально, но на первичном сервере начались жуткие тормоза. Посмотрели - нити находятся в ожидании освобождения буфера лог журналв, отключили реплиацию - все ОК. Ну вот здесь наверное и проблема: вы загрузили вторичный сервер запросами, в результате теперь накат транзакций на вторичном конкурирует за ресурсы с сессиями на вторичном. Уровень изоляции для пользователей на вторичном всегда dirty read, так что они не должны никого блокировать, проблема скорее всего именно с большой загрузкой вторичного. ... на вторичном сервер вроде бы как нагрузки при этом большой нет - а может не туда смотрел. может и в самом деле не туда смотрели Еще можно проверить задержки в сети: соберите пинг статистику в разных направлениях (размер пакета задайте побольше, например 4к) Варианты с отдельным сетевым интерфейсом для репликации и перевод БД в BUF пока не рассматриваем. Т.е. у вас есть базы с небуферизованным режимом журналирования? В таком случае при каждой фиксации транзакции в такой базе буфер логического журнала будет сбрасываться на диск и в буфер репликации, и отправка этого буфера на вторичный. Сетевой трафик будет больше из-за того что буфер репликации отсылается на вторичный чаще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2006, 09:52 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
Полностью согласен с Andron-ом. Думаю, что на вторичный сервер вы повесили немодифицирующих пользователей типа "создание отчетов", которые могут хорошо грузить систему или, как минимум, тот же сетевой трафик. Опять же, при увеличенной частоте сброса буферов логжурнала на первичке, эти журналы еще и практически пустые (только с одной транзакцией), но, боюсь, что передаются они полностью. Совет: оставить все таки в покое вторичный сервер для выполнения основного назначения - обеспечения надежности и доступности инфомации. Для других целей, похоже, он предназначен плохо (см.например http://www.sql.ru/forum/actualthread.aspx?tid=277313#3347331 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2006, 19:48 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
Кстати, возможно что на вторичном (или на основном) помимо информикса работают и другие приложения, которые тоже могут сильно грузить систему. Кроме того, может быть железо слабое. Все таки использовать вторичный для отчетов можно - у нас такая система работает неплохо несколько лет (используем буферизованное журналирование в базах). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 10:49 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
А можно увидеть onstat -l |head -n 15 А сколько LOGBUFF ? Уменьшить не пробовали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 11:20 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
1. Журналирование с буферизацией - давайте пока закроем тему. 2. На вторичный сервер передаются не логи, а буфера. Интенсивность не большая - в среднем около 50-60 транзакций в секунду или около 138КБ в секунду. LOGBUFF 256 - можно конечно уменьшить. 3. Сетевой трафик не нагружен, отклик не отличается в разные моменты времени. 4. Вторичный сервер действительно значительно слабее первичного. 5. Тормоза на вторичном сервере действительно есть. Вероятнее всего проблема связана с обработкой контрольной точки на вторичном сервере - порядка 3 секунд. В течение этого времени, вероятнее всего вторичный сервер не может принимать буфера репликации. Что такое контрольная точка на вторичном сервере - слабо себе представляю, вероятнее всего просто очистка физ. журнала. Скорее всего придется пересобрать RAID и физ. журнал вынести на отдельный диск. Хотя вынос журналов на отдельные диски и расписан в доке, но в большинстве случаев эффективнее использование одной "большой колбасы", да и не всегдв получается вынести на отдельный диск так как рекомендует дока (нет столько дисков). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 12:09 |
|
||
|
тормоза HDR
|
|||
|---|---|---|---|
|
#18+
Igor Zaiets 2. На вторичный сервер передаются не логи, а буфера. Интенсивность не большая - в среднем около 50-60 транзакций в секунду или около 138КБ в секунду. LOGBUFF 256 - можно конечно уменьшить. 4. Вторичный сервер действительно значительно слабее первичного. Мне кажется, что размер буферов логжурнала надо обязательно уменьшать до стандартных 32. Тем более, что база небуферизированная. Даже на буферизируемых БД никогда не видел, чтобы эффективно использовался буфер такого размера. Максимум - 64. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 15:55 |
|
||
|
|
start [/forum/topic.php?fid=44&msg=34221777&tid=1608488]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 225ms |
| total: | 396ms |
| 0 / 0 |
