2012-02-21 2 views
2

У нас есть Thin + RoR с приложением ActiveRecord + memcached + Postgres, которое использует жемчужину pg для доступа к базе данных Postgres.Тонкий подвешенный под большой нагрузкой

Мы наблюдаем, что при высокой нагрузке тонкие процессы внезапно перестают реагировать друг на друга и никогда не восстанавливаются при снижении нагрузки. Тем временем наш сервер базы данных работает нормально - мы можем запросить данные и получить ответ в ожидаемое время.

Вещи, которые мы наблюдали:

  • Мы не видим медленное увеличение времени отклика, прежде чем мы получим в плохом состоянии - переход внезапно.
  • Мы можем попасть в это состояние с одним или с несколькими тонкими процессами, что, по-видимому, исключает возможность их взаимной блокировки при нагрузке.
  • Когда груз утихает, тонкие процессы не восстанавливаются и продолжают не реагировать.
  • После того, как вы повесили тонкий процесс, похоже, не выдавали никаких запросов в БД.
  • ввп указывает на то, что, когда в зависшем состоянии, у нас есть тонкие нити в состоянии sleep_forever: 0x00007f75c78c85d2 в sleep_forever (Arg =) на thread.c: 848

Имея в виду, что это 95% приложений для чтения с более или менее агрессивной стратегией кэширования (т.е. у нас нет транзакций базы данных, которые могут вызвать взаимоблокировки), мы ищем предложения о том, где искать.

Большое вам спасибо за помощь! Дополнительно:

Драгоценные камни:

  • Gem 'рельсы', '2.3.11'
  • Gem 'тонкий', '1.2.7'
  • Gem '' Pg

Окружающая среда:

  • PSQL (PostgreSQL) 9.1.2
  • Тонкие
  • 1.2.7
  • Рубин 1.9.2-P290
  • Рельсы 2.3.11
  • Apache 2.2.14 (подробности ниже)
 
Server version: Apache/2.2.14 (Ubuntu) 
Server built: Feb 14 2012 16:42:27 
Server's Module Magic Number: 20051115:23 
Server loaded: APR 1.3.8, APR-Util 1.3.9 
Compiled using: APR 1.3.8, APR-Util 1.3.9 
Architecture: 64-bit 
Server MPM:  Worker 
    threaded:  yes (fixed thread count) 
    forked:  yes (variable process count) 
Server compiled with.... 
-D APACHE_MPM_DIR="server/mpm/worker" 
-D APR_HAS_SENDFILE 
-D APR_HAS_MMAP 
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) 
-D APR_USE_SYSVSEM_SERIALIZE 
-D APR_USE_PTHREAD_SERIALIZE 
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT 
-D APR_HAS_OTHER_CHILD 
-D AP_HAVE_RELIABLE_PIPED_LOGS 
-D DYNAMIC_MODULE_LIMIT=128 
-D HTTPD_ROOT="" 
-D SUEXEC_BIN="/usr/lib/apache2/suexec" 
-D DEFAULT_PIDLOG="/var/run/apache2.pid" 
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status" 
-D DEFAULT_ERRORLOG="logs/error_log" 
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types" 
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf" 
[email protected]:~# /usr/sbin/apache2 -v 
Server version: Apache/2.2.14 (Ubuntu) 
Server built: Feb 14 2012 16:42:27 

ответ

2

Это была проблема со стеком TCP в ruby: http://bugs.ruby-lang.org/issues/5343

Попробуйте модернизировать до ruby ​​1.9.3 или выше.

+0

Большое спасибо. Это выглядит очень актуально - трассировки стека идентичны, но после того, как мы обновили ti 1.9.3, проблема все еще сохраняется. –

+0

В конце концов мы перешли от тонкого к единорогу, что позволяет избежать этого вообще - может быть, это все еще проблема в 1.9.3? – Brett

+0

На самом деле это именно то, что мы закончили. Мы переключились на единорога, этот вопрос больше не повторяется для нас. –

1

Мы закончили тем, что перешли от Тонкого к Единорогу. Проблемы исчезли.

+0

Это может указывать на проблему безопасности потока. – mtkd

Смежные вопросы