Zenn
🧯

[10年間を振り返る] 苦戦したサーバートラブルMy4選

2020/09/27に公開
PostgreSQL
thp
glusterfs
keepalived
NFS
tech

published_at: 2019-09-29 01:20

Twitterで先週(2019/09/25頃) #10年間を振り返る [1] というトレンドにちょっとのっかってみて、
そういえばこんなことあったなあというトラブルを共有してみる気になったのでまとめました。

1. RHEL7 THP(Transparent Huge Page)

屈強のはずの物理サーバーが悲鳴を上げている理由、１ヶ月くらいわからなかった

現象/傾向

  • PostgreSQL のDBサーバーのCPUが急激に高負荷状態に陥る場合がある/頻発する
  • 通常の傾向として、CPU system time の割合がやや高い

対策/回避策

  • THP を無効にして OS を再起動する

参考情報

2. GlusterFS remove-brick

容量問題でノードを増やしていったけど結局は管理対象の数が少ない方がいいよねという結論となり減らしていこうとしたらまあ死んだ

現象/傾向

  • 大量アクセス気味の状況下で remove-brick の処理とバッディングすると
    • 一部のノードサーバーが高負荷に陥る場合がある
    • ファイルが正しく参照できない状態に陥る場合がある

対策/回避策

参考情報

3. keepalived VIPが切り替わらない

冗長化してあるから大丈夫だろうって思い込みはダメで、簡単そうなこともちゃんとわかって検証もしてからやらないと

現象/傾向

  • MASTER STATE の(?) keepalived をプロセス再起動したら負荷分散先にトラフィックが流れなくなって障害
    • 想定通りにフェールオーバーしていなかった

対策/回避策

  • 一時的に、上位にあったリバースプロキシから直接スペックの高いWebサーバーにトラフィックを流すようにして障害を暫定回避
  • ↓の情報を見つけて、今後はどこがVIP持ってるか確認しましょうね、という教訓を生やした

参考情報

4. NFS 20万ファイルのlsが劇遅

どんだけファイルあるのよって見てみようとしたらそれが火に油で、一歩離れたところから見えるようにしておかないとね、を痛感した

現象/傾向

  • NFSでファイル共有しているディレクトリに20万を超えるファイルがあるとlsコマンド実行した時にハングアップ状態になりシステムのパフォーマンスが致命的に劣化

対策/回避策

  • 一定時間経過を超えたファイルを削除して凌いだ
  • 再発防止のために、それの自動化とファイル数の監視を入れた

参考情報

番外編

こんなのも見たことあるんですがだいぶ昔だったり深く思い出せなかったりなので項目程度に

CloudStack 上のVM OS再起動後に resolv.conf が変わっている

VM をOS再起動したら疎通が不調で、追いかけたらデフォルトの resolv.conf になっちゃってた。
/etc/resolv.conf を配布して nscd restart (だったかな) を並列実行させて解消させていたような。

PostgreSQL 実行計画が更新されずにパフォーマンス劣化

とても列数が多いテーブルに行もどんどん溜まるようなケースで、タイミングを見つけられないのか期待しているようにAuto VACCUM が走らず、クエリーの滞留が多くなったりした。
手動で ANALYZE する と解消できていた。

RAIDの自動復旧（?自動リビルドだったかも）が機能しない

中途半端に機能しないものだから修復がなかなか進まず、障害が長期化。
多少のリスクあるとは聞いていたがその自動なんちゃらを強制停止して手動復旧に舵を切ったと記憶している。介錯するのも情け、と思った件。

その他

元ネタ？はこちら。

脚注

  1. #10年を振り返る #10年間振り返る など類似形あり ↩︎

Discussion