<p>published_at: 2019-09-29 01:20</p>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p>これは自身の記事を、サービス終了に伴い Qrunch から移行したものです</p>
</div></aside>
<hr>
<p>Twitterで先週(2019/09/25頃) <a href="https://twitter.com/search?q=%2310%E5%B9%B4%E9%96%93%E3%82%92%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8B%20%40sogaoh%20since%3A2019-09-20%20until%3A2019-09-29&amp;src=typed_query&amp;f=live" target="_blank" rel="nofollow noopener noreferrer">#10年間を振り返る</a> <sup class="footnote-ref"><a href="#fn-c575-1" id="fnref-c575-1">[1]</a></sup> というトレンドにちょっとのっかってみて、<br>
そういえばこんなことあったなあというトラブルを共有してみる気になったのでまとめました。</p>
<h2 id="1.-rhel7-thp(transparent-huge-page)">
<a class="header-anchor-link" href="#1.-rhel7-thp(transparent-huge-page)" aria-hidden="true"></a> 1. RHEL7 THP(Transparent Huge Page)</h2>
<p>屈強のはずの物理サーバーが悲鳴を上げている理由、１ヶ月くらいわからなかった</p>
<h3 id="%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91">
<a class="header-anchor-link" href="#%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91" aria-hidden="true"></a> 現象/傾向</h3>
<ul>
<li>PostgreSQL のDBサーバーのCPUが急激に高負荷状態に陥る場合がある/頻発する</li>
<li>通常の傾向として、CPU system time の割合がやや高い</li>
</ul>
<h3 id="%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96">
<a class="header-anchor-link" href="#%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96" aria-hidden="true"></a> 対策/回避策</h3>
<ul>
<li>THP を無効にして OS を再起動する</li>
</ul>
<h3 id="%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1">
<a class="header-anchor-link" href="#%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1" aria-hidden="true"></a> 参考情報</h3>
<ul>
<li><a href="https://qiita.com/Morihaya/items/d09f6f41ba3c374b8cc2" target="_blank" rel="nofollow noopener noreferrer">[postgres]大容量メモリかつOSがRHEL(CentOS)6系をお使いの方、THPのdefragは止めた方が良いですよ</a></li>
</ul>
<h2 id="2.-glusterfs-remove-brick">
<a class="header-anchor-link" href="#2.-glusterfs-remove-brick" aria-hidden="true"></a> 2. GlusterFS remove-brick</h2>
<p>容量問題でノードを増やしていったけど結局は管理対象の数が少ない方がいいよねという結論となり減らしていこうとしたらまあ死んだ</p>
<h3 id="%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91-1">
<a class="header-anchor-link" href="#%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91-1" aria-hidden="true"></a> 現象/傾向</h3>
<ul>
<li>大量アクセス気味の状況下で remove-brick の処理とバッディングすると
<ul>
<li>一部のノードサーバーが高負荷に陥る場合がある</li>
<li>ファイルが正しく参照できない状態に陥る場合がある</li>
</ul>
</li>
</ul>
<h3 id="%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96-1">
<a class="header-anchor-link" href="#%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96-1" aria-hidden="true"></a> 対策/回避策</h3>
<ul>
<li>GlusterFSからDRBDへのリプレース
<ul>
<li><a href="https://wanderer.sogaoh.space/posts/2018/02/26/1/" target="_blank" rel="nofollow noopener noreferrer">GlusterFS(3.3)からの脱却に成功した2018.2.7</a></li>
</ul>
</li>
</ul>
<h3 id="%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1-1">
<a class="header-anchor-link" href="#%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1-1" aria-hidden="true"></a> 参考情報</h3>
<ul>
<li><a href="https://sites.google.com/site/glusterfstech/volumes/modify#TOC--7" target="_blank" rel="nofollow noopener noreferrer">GlusterFS技術情報 &gt; ボリューム構成変更手順 &gt; ブリックの削除</a></li>
<li><a href="https://github.com/gluster/glusterfs" target="_blank" rel="nofollow noopener noreferrer">https://github.com/gluster/glusterfs</a></li>
</ul>
<h2 id="3.-keepalived-vip%E3%81%8C%E5%88%87%E3%82%8A%E6%9B%BF%E3%82%8F%E3%82%89%E3%81%AA%E3%81%84">
<a class="header-anchor-link" href="#3.-keepalived-vip%E3%81%8C%E5%88%87%E3%82%8A%E6%9B%BF%E3%82%8F%E3%82%89%E3%81%AA%E3%81%84" aria-hidden="true"></a> 3. keepalived VIPが切り替わらない</h2>
<p>冗長化してあるから大丈夫だろうって思い込みはダメで、簡単そうなこともちゃんとわかって検証もしてからやらないと</p>
<h3 id="%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91-2">
<a class="header-anchor-link" href="#%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91-2" aria-hidden="true"></a> 現象/傾向</h3>
<ul>
<li>MASTER STATE の(?) keepalived をプロセス再起動したら負荷分散先にトラフィックが流れなくなって障害
<ul>
<li>想定通りにフェールオーバーしていなかった</li>
</ul>
</li>
</ul>
<h3 id="%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96-2">
<a class="header-anchor-link" href="#%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96-2" aria-hidden="true"></a> 対策/回避策</h3>
<ul>
<li>一時的に、上位にあったリバースプロキシから直接スペックの高いWebサーバーにトラフィックを流すようにして障害を暫定回避</li>
<li>↓の情報を見つけて、今後はどこがVIP持ってるか確認しましょうね、という教訓を生やした</li>
</ul>
<h3 id="%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1-2">
<a class="header-anchor-link" href="#%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1-2" aria-hidden="true"></a> 参考情報</h3>
<ul>
<li><a href="https://qiita.com/tkit/items/18040c31c75fb3814964" target="_blank" rel="nofollow noopener noreferrer">keepalivedが異常終了したらvipを手動で消す必要がある</a></li>
</ul>
<h2 id="4.-nfs-20%E4%B8%87%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AEls%E3%81%8C%E5%8A%87%E9%81%85">
<a class="header-anchor-link" href="#4.-nfs-20%E4%B8%87%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AEls%E3%81%8C%E5%8A%87%E9%81%85" aria-hidden="true"></a> 4. NFS 20万ファイルのlsが劇遅</h2>
<p>どんだけファイルあるのよって見てみようとしたらそれが火に油で、一歩離れたところから見えるようにしておかないとね、を痛感した</p>
<h3 id="%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91-3">
<a class="header-anchor-link" href="#%E7%8F%BE%E8%B1%A1%2F%E5%82%BE%E5%90%91-3" aria-hidden="true"></a> 現象/傾向</h3>
<ul>
<li>NFSでファイル共有しているディレクトリに20万を超えるファイルがあるとlsコマンド実行した時にハングアップ状態になりシステムのパフォーマンスが致命的に劣化</li>
</ul>
<h3 id="%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96-3">
<a class="header-anchor-link" href="#%E5%AF%BE%E7%AD%96%2F%E5%9B%9E%E9%81%BF%E7%AD%96-3" aria-hidden="true"></a> 対策/回避策</h3>
<ul>
<li>一定時間経過を超えたファイルを削除して凌いだ</li>
<li>再発防止のために、それの自動化とファイル数の監視を入れた</li>
</ul>
<h3 id="%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1-3">
<a class="header-anchor-link" href="#%E5%8F%82%E8%80%83%E6%83%85%E5%A0%B1-3" aria-hidden="true"></a> 参考情報</h3>
<ul>
<li>
<a href="https://access.redhat.com/ja/solutions/2734211" target="_blank" rel="nofollow noopener noreferrer">大規模な NFS ディレクトリで ls コマンドがハングアップする</a>
<ul>
<li>Red Hat subscription アカウント持ってないと最後までは読めないです 🙇‍️</li>
</ul>
</li>
</ul>
<h2 id="%E7%95%AA%E5%A4%96%E7%B7%A8">
<a class="header-anchor-link" href="#%E7%95%AA%E5%A4%96%E7%B7%A8" aria-hidden="true"></a> 番外編</h2>
<p>こんなのも見たことあるんですがだいぶ昔だったり深く思い出せなかったりなので項目程度に</p>
<h3 id="cloudstack-%E4%B8%8A%E3%81%AEvm-os%E5%86%8D%E8%B5%B7%E5%8B%95%E5%BE%8C%E3%81%AB-resolv.conf-%E3%81%8C%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B">
<a class="header-anchor-link" href="#cloudstack-%E4%B8%8A%E3%81%AEvm-os%E5%86%8D%E8%B5%B7%E5%8B%95%E5%BE%8C%E3%81%AB-resolv.conf-%E3%81%8C%E5%A4%89%E3%82%8F%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B" aria-hidden="true"></a> CloudStack 上のVM OS再起動後に resolv.conf が変わっている</h3>
<p>VM をOS再起動したら疎通が不調で、追いかけたらデフォルトの resolv.conf になっちゃってた。<br>
/etc/resolv.conf を配布して nscd restart (だったかな) を並列実行させて解消させていたような。</p>
<h3 id="postgresql-%E5%AE%9F%E8%A1%8C%E8%A8%88%E7%94%BB%E3%81%8C%E6%9B%B4%E6%96%B0%E3%81%95%E3%82%8C%E3%81%9A%E3%81%AB%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E5%8A%A3%E5%8C%96">
<a class="header-anchor-link" href="#postgresql-%E5%AE%9F%E8%A1%8C%E8%A8%88%E7%94%BB%E3%81%8C%E6%9B%B4%E6%96%B0%E3%81%95%E3%82%8C%E3%81%9A%E3%81%AB%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E5%8A%A3%E5%8C%96" aria-hidden="true"></a> PostgreSQL 実行計画が更新されずにパフォーマンス劣化</h3>
<p>とても列数が多いテーブルに行もどんどん溜まるようなケースで、タイミングを見つけられないのか期待しているようにAuto VACCUM が走らず、クエリーの滞留が多くなったりした。<br>
<a href="https://www.postgresql.jp/document/9.6/html/sql-analyze.html" target="_blank" rel="nofollow noopener noreferrer">手動で ANALYZE する</a> と解消できていた。</p>
<h3 id="raid%E3%81%AE%E8%87%AA%E5%8B%95%E5%BE%A9%E6%97%A7%EF%BC%88%3F%E8%87%AA%E5%8B%95%E3%83%AA%E3%83%93%E3%83%AB%E3%83%89%E3%81%A0%E3%81%A3%E3%81%9F%E3%81%8B%E3%82%82%EF%BC%89%E3%81%8C%E6%A9%9F%E8%83%BD%E3%81%97%E3%81%AA%E3%81%84">
<a class="header-anchor-link" href="#raid%E3%81%AE%E8%87%AA%E5%8B%95%E5%BE%A9%E6%97%A7%EF%BC%88%3F%E8%87%AA%E5%8B%95%E3%83%AA%E3%83%93%E3%83%AB%E3%83%89%E3%81%A0%E3%81%A3%E3%81%9F%E3%81%8B%E3%82%82%EF%BC%89%E3%81%8C%E6%A9%9F%E8%83%BD%E3%81%97%E3%81%AA%E3%81%84" aria-hidden="true"></a> RAIDの自動復旧（?自動リビルドだったかも）が機能しない</h3>
<p>中途半端に機能しないものだから修復がなかなか進まず、障害が長期化。<br>
多少のリスクあるとは聞いていたがその自動なんちゃらを強制停止して手動復旧に舵を切ったと記憶している。介錯するのも情け、と思った件。</p>
<h2 id="%E3%81%9D%E3%81%AE%E4%BB%96">
<a class="header-anchor-link" href="#%E3%81%9D%E3%81%AE%E4%BB%96" aria-hidden="true"></a> その他</h2>
<p>元ネタ？はこちら。</p>
<span class="embed-block zenn-embedded zenn-embedded-tweet"><iframe id="zenn-embedded__2e00e119e44cc" src="https://embed.zenn.studio/tweet#zenn-embedded__2e00e119e44cc" data-content="https%3A%2F%2Ftwitter.com%2Fsogaoh%2Fstatus%2F1176521152413360129" frameborder="0" scrolling="no" loading="lazy"></iframe></span>
<section class="footnotes">
<span class="footnotes-title">脚注</span>
<ol class="footnotes-list">
<li id="fn-c575-1" class="footnote-item">
<p>#10年を振り返る #10年間振り返る など類似形あり <a href="#fnref-c575-1" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


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

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

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

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

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

Discussion