проблемы очереди писцов в фейсбуке - PullRequest
Новая
       20

проблемы очереди писцов в фейсбуке

0 голосов
/ 08 декабря 2011

мы используем писец так:

  • Веб-сервер (SA) ---> Локальный сервер Scribe (SB)

    • Веб-сервер (SA) и локальный сервер Scribe (SB) на одном компьютере;
    • Веб-сервер просто отправляет все журналы писцу максимум 3 раза, после повторной попытки 2 раза мы просто отбрасываем их.
    • Локальный сервер Scribe использует буферное хранилище, первичное использование сетевого хранилища отправляет журналы следующему Collector Scribe BJ, а вторичное записывает журнал на локальный диск, и мы устанавливаем max_queue_size = 1000000000 и max_queue_length = 20000000.

  • ----> Сборщик Scribe BJ (SC) ---- ssh туннель (сжатый gzip) --- vpn ---> Сборщик Scribe SH (SD)

    • Сборщик Scribe BJ (SC) и локальный Scribe Server (SB) в одной локальной сети.
    • Collector Scribe BJ (SC) использует несколько хранилищ, store0 использует хранилище буферов, store0 первично использует сетевое хранилище, отправляет журналы следующему Collector Scribe SH, а вторичное устройство store0 записывает журнал на локальный диск, и мы устанавливаем max_queue_size = 10000000 и max_queue_length = 2000000.
    • Collector Scribe BJ (SC) использует store0 - буферное хранилище - сеть первичного хранилища отправляет журналы на локальный порт и через туннель ssh отправляет сообщения из IDC BJ в IDC SH.
    • Наконец писец-сборщик SH (SD) использует хранилище файлов std и записывает журналы на свой диск.

Вот мои вопросы.

  • Вопрос 1: Я не могу найти использование опции max_queue_length в исходном коде писца. А также я нахожу некоторую информацию, упомянутую в googlegroup, что max_queue_length устарела. Так что здесь ничего не эффективно с использованием "max_queue_length = 20000000"?

  • Вопрос 2: Просто опция max_queue_length "если количество сообщений в очереди превышает это значение, хранилище буфера переключится на запись во вторичное хранилище (описано в вики githup)" может контролировать, когда писец хранилища буфера может переключить первичное хранилище на вторичный магазин. Когда max_queue_length бесполезна, как я могу управлять буферным хранилищем, переключая первичное хранилище на вторичное хранилище?

  • Вопрос 3: Когда скорость записи вторичного хранилища Local Scribe Server (SB) превышает скорость ввода данных веб-сервера (SA), все равно Local Scribe Server (SB) не потеряет данные?

  • Вопрос 4: Я также нахожу график в googlegroup, который упоминал inder.pall. Вот ссылка: http://scribe -server.googlegroups.com / присоединять / 979f9ffbe00f5eb3 / Screen + выстрел + 2011-11-22 + при + 9.12.32 + AM.png GDA = FIJ3I0cAAACFwDSo_bUG96Wo0CVG6AlpKMzYsToU_WRZEGbv_RKdbkT0wWvVm1xmkWqWMWNxOm4bQwFxJw55cVwemAxM-EWmeV4duv6pDMGhhhZdjQlNAw & зрения = 1 & часть = 4? Я думаю, что только когда писец недоступен (не активен и тайм-аут) или размер его очереди больше, чем max_queue_size, он вернет TRY_LATER своему писцу восходящего направления. В это время его переписчик будет создавать резервные копии сообщений на вторичном сервере?

  • Вопрос 5: Как уже упоминалось в вопросе 4, когда vpn (BJ - SH) очень занят и задержка очень велика, но туннель доступен, и писец коллектора SH (SD) не возвращает TRY_LATER и ясно, что коллекторный писец BJ (SC) ' входная скорость больше, чем его выходная скорость в туннель, поэтому память Collector Scribe BJ (SC) будет непрерывно увеличиваться и не будет использовать вторичное хранилище?

1 Ответ

0 голосов
/ 03 января 2012

Я боролся с такими же / похожими вопросами в прошлом месяце. Благодаря людям, использующим писец, я нашел некоторые ответы:

  1. Так что здесь ничего не эффективно с использованием "max_queue_length = 20000000"? Ответ: Вы правы, max_queue_length удалена, и ничто другое не заменяет функциональность. max_queue_length, на мой взгляд, имеет большее значение, чем это видно на первый взгляд. Например: max_queue_length может помочь рывку и предотвратить TRY_AGAIN (s), которые возникают, когда входные буферы (сервера писцов) заполнены. Если вы хотите, вы можете отменить изменения, которые вывели max_queue_length из кода писца. Вот набор изменений: https://github.com/facebook/scribe/commit/1b5d5c89a40c737ed7fa9a028f490bf336cd0da8

  2. Когда max_queue_length бесполезна, как я могу управлять буферным хранилищем, переключая первичное хранилище на вторичное хранилище? Ответ. Вы будете ждать, пока первичное хранилище не отправит сообщения об ошибках (EAGAIN - out of resouce) или TRY AGAIN, или max_queue_size вашего сервера переписчиков, и затем вы начнете запись в ваше вторичное хранилище. В этом случае соединение первичного хранилища переходит в режим ОТКЛЮЧЕНО. После восстановления соединения (на основе retry_interval и retry_interval_range) сообщения из вторичного хранилища будут «воспроизводиться» в первичное хранилище.

3.Когда скорость записи вторичного хранилища Local Scribe Server (SB) превышает скорость ввода данных веб-сервера (SA), все равно Local Scribe Server (SB) не потеряет данные? Ответ: Я полагаю, что нет, если только у вас нет асинхронных приложений, пишущих на сервер писцов, или если вторичное хранилище не заполнено! ... или ваш сервер переписки выходит из строя, и в этом случае я сожраю сообщения, равные max_size.

  1. ... TRY_LATER своему писцу. В это время его переписчик будет делать резервные копии сообщений на вторичном? Ответ: да. Как я уже упоминал в ответе на первый вопрос.

  2. ... Память коллекционера Scribe BJ (SC) будет постоянно увеличиваться и не будет использовать вторичное хранилище? Ответ: Я думаю, вы уже догадались до ответа. В этом сценарии ваш сервер переписчиков отправит TRY_AGAIN вверх по течению и ожидает, что записывающие на него надстройки снизят скорость записи.

Также вы можете найти это полезным: http://groups.google.com/group/scribe-server/browse_thread/thread/ec2b1b641a968c0b

-Abhinav

...