2
Postgresデータベースにアクセスするためにpg gemを使用しているActiveRecord + memcached + PostgresアプリケーションのThin + RoRがあります。高負荷下でのシンハンギング
高負荷の薄いプロセスでは、突然応答がなくなり、負荷が降下したときに回復しないことがわかりました。当時のデータベースサーバは正常に動作しています。データを照会して、予想される時間内に応答を得ることができます。我々が観察している
もの：
- 我々は悪い状態に入る前に、私たちは、応答時間の遅い増加が表示されない - 移行は突然です。
- 1つまたは複数のシンプロセスでその状態になることができます。これは、負荷がかかって互いにデッドロックする可能性を排除しているようです。
- 負荷が低下すると、シンプロセスは回復せず、応答しなくなります。
- ハングすると、シンプロセスはDBに要求を出さないようです。
- GDPがハング状態で、我々はsleep_forever状態で薄いのスレッドがある場合指摘：sleep_foreverで0x00007f75c78c85d2（引数=）thread.cで：これは95％の読み取りアプリケーションであることを念頭に置いて848
キーピングを多かれ少なかれ攻撃的なキャッシング戦略（デッドロックを引き起こす可能性のあるデータベーストランザクションはありません）を使用して、どこを探すべきかについての提案を探しています。
ご協力いただきありがとうございます。余分な情報：
宝石：
- 宝石 'レール'、 '薄い' '2.3.11'
- 宝石、 '1.2.7'
- 宝石 'PG'
環境：
- のpsql（PostgreSQLの）9.1.2
- シン1.2.7
- ルビー1.9.2-P290
- のRails 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
ありがとうございます。スタックトレースは同じですが、1.9.3をアップグレードした後でも問題は解決しません。 –
Hrm私たちは最終的にこれを完全に避ける薄型からユニコーンに切り替えました。おそらく1.9.3の問題でしょうか？ – Brett
これは実際に私たちがやったこととまったく同じです。私たちはユニコーンに切り替えましたが、問題はもはや私たちのための報酬ではありません。 –