20140828 #ssmjp 社内チューニンガソンで優勝したはなし

社内チューニンガソンで   優勝したはなし 2014-­‐08-­‐28  #ssmjp     Aki@nekoruri

自己紹介 • Aki  /  @nekoruri  /  id:nekoruri   – 某CA社のなかのひと   – 入社14ヶ月目   – 秋葉原生まれ大手町育ちの歌って踊れる   江戸っ子フルスタックインフラエンジニア  

社内チューニンガソン   「TOTEC2014」 • 昨年までは新卒のみで実施、今年から拡大 • 3部門で実施   – インフラ：ミドルウェア   – フロントエンド：HTML+CSS+JS   – サーバサイド：言語を問わないAPI開発   – 各100人（新卒50/他50）を予選で選抜  

インフラチューニング • ソースコード「より下」のチューニング   – いわゆる「チューニンガソン」そのもの   – ミドルウェアの選定、チューニング   – サーバ構成の最適化  

今回のお題 ＿人人人人人人＿ ＞ MediaWiki ＜ ￣Y^Y^Y^Y^Y^Y￣

主なガイドライン • • • • • • • 用意されたMediaWikiの応答速度を競う   ソース修正禁止（設定ファイルは可）   複数のURLの応答速度の合算（式は非公表）   渡されたサーバ4台は自由に使える   DBはMySQL互換のみ（＝ダンプが食える）   ディスクへの書き出しが必須   終了直後にサーバ再起動

最終的なサーバ構成 計測用   サーバ 運営からの速度計測リクエスト キャッシュ破棄リクエスト   (MediaWikiの標準機能) Varnish3 nginx nginx nginx nginx PHP  5.5 PHP  5.5 PHP  5.5 PHP  5.5 固定100プロセス   （DB同居のDは50） MySQL  5.6 memcached サーバA サーバB サーバC サーバD

方針 1. おれ達のMediaWikiがそんなにチューニング されていないわけがない   – ですよねー   2. 飛び道具は後半から   – Varnish速いとか、しし知ってるし（震え声）   3. 割り切り   – 細かくベンチ取って比較してると時間足りない   – 手間の割に効果が薄いことはどんどん後回し

11:00   開始 • 初期状態の保存   – /etcをまるっと保存   – rpm  -­‐qa  |  sort     • 環境の調査   この時点で   OSチューニングも   捨てる – Amazon  Linux   – 4台全部c3.large   – ディスク構成も素のまま   • 性能監視   – dstat,  munin  

11:30   nginx  +  php-­‐fpm導入 • Apache+mod_php5だったらしい   – PHPプロセス数  ＝Apacheプロセス数    ＝同時接続数   疎結合だいじ！   とてもだいじ！！ • みんなだいすきnginx  +  php-­‐fpmを導入   – FastCGI層でPHPプロセスを分離   – （転送遅いリクエストもnginxにおまかせ）   • ついでにPHP5.4から5.5   – APCのかわりにOpcache＋APCu  

12:00   設定の試行錯誤 • 運営の計測   – 5分間隔（ぐらい）   – これドリブンで動くと永遠に時間が掛かる   (うえに施策と計測で時差が出る) • 自分でabで計測   – アクセスログに出る計測リクエストを眺めつつ # ab -k -c10 -n1000 'localhost/wiki/index.php?title= %E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8' Requests per second: 18.15 [#/sec] (mean)

PHPとMySQLの負荷 # top top - 12:12:24 up 3:59, 2 users, load average: 3.31, 4.30, 2.72 Tasks: 89 total, 2 running, 87 sleeping, 0 stopped, 0 zombie Cpu(s): 40.0%us, 1.5%sy, 0.0%ni, 57.3%id, 1.0%wa, 0.0%hi, 0.0%si, 0.2%st Mem: 3859076k total, 1750232k used, 2108844k free, 94156k buffers Swap: 0k total, 0k used, 0k free, 1279920k cached MySQLもおもい PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2652 mysql 20 0 1335m 99m 6184 S 13.0 2.7 7:12.04 mysqld 25668 nginx 20 0 463m 35m 18m S 9.3 0.9 0:03.38 php-fpm-5.5 25665 nginx 20 0 459m 31m 18m S 9.0 0.8 0:03.37 php-fpm-5.5 25670 nginx 20 0 457m 29m 17m S 9.0 0.8 0:03.54 php-fpm-5.5 25667 nginx 20 0 459m 31m 17m S 8.0 0.8 0:03.07 php-fpm-5.5 25669 nginx 20 0 459m 31m 18m S 8.0 0.8 0:03.24 php-fpm-5.5 25662 nginx 20 0 457m 29m 17m S 7.7 0.8 0:03.24 php-fpm-5.5 PHPがおもい 25663 nginx 20 0 457m 29m 18m S 6.7 0.8 0:03.22 php-fpm-5.5 25664 nginx 20 0 461m 33m 18m S 6.0 0.9 0:03.03 php-fpm-5.5 25661 nginx 20 0 459m 31m 17m R 5.7 0.8 0:03.22 php-fpm-5.5 25666 nginx 20 0 457m 29m 17m S 3.7 0.8 0:03.01 php-fpm-5.5 25693 totec201 20 0 15140 1196 912 R 0.3 0.0 0:00.03 top 1 root 20 0 19488 1596 1280 S 0.0 0.0 0:00.74 init

13:00   DBチューニング • とりあえずそれっぽい設定をいれる   – kazeburoさんが公開しているmy.cnf     MySQLの設定ファイル my.cnf  をgithubにて公開しました &  チューニングポイントの紹介 hdp://blog.nomadscafe.jp/2012/10/mysql-­‐mycnf-­‐github.html   – 若干の手心   • innodb_flush_log_at_trx_commit=0   • クエリキャッシュの有効化  

集計クエリとの戦い • 重いクエリの特定   – 「moreEdit」問題   • 秒単位でかかるのでタイムアウト扱い＝ペナルティ   – 集計系のクエリが死ぬほど重い   • 試行錯誤   – – – – – sort_bufferの思い切った引き上げ   クエリキャッシュ有効化   upgrade  to  MySQL  5.6   （時間が合ったら：mysql-­‐proxyでクエリ書換）   ここで保留を決定（どうせVarnishするし）

14:00   銀の弾丸Varnish登場 • ググレカス   – Google:「MediaWiki  Varnish」   ⇒  Manual:Varnish  caching  –  MediaWiki      hdp://www.mediawiki.org/wiki/Manual:Varnish_caching   – さすがおれ達のMediaWiki！！！   – 10倍界王拳に成功！  

15:00	
  
Varnishの調整	
• ログ強化	
  
#	
 vim	
 /etc/sysconfig/varnishncsa:	
 
DAEMON_OPTS="-a	
 -w	
 $logfile	
 -D	
 -P	
 $pidfile	
 -F	
 '%h	
 %l	
 %u	
 %t	
 \"%r\"	
 %s	
 %b	
 %D	
 fb:%
{Varnish:time_firstbyte}x	
 hit:%{Varnish:hitmiss}x	
 hdl:%x{Varnish:handling}x'"	
 
	
 
#	
 sort	
 -n	
 -k11	
 	
 /var/log/varnish/varnishncsa.log	
 |	
 less	
 

• 数万リクエストなのでmallocにしてみる	
  

PURGE • Varnishの天敵   – 「更新されたページがキャッシュされ続ける」   – おれ達のMediaWikiにはPURGE処理が標準！   ……設定忘れてたorz   – これ入れる直前がピーク（93064）  

16:00   サーバの分散 • とりあえずPHPで稼ぐ   – 最終的に4台全部に載せる   – DBと相乗りの子だけワーカー減らす   本当はVarnishから の振り分け率を   変えないとダメ

17:00   ラストスパート • 運用？しらないね。   – 監視全部カット   – ログ全部カット   • 要らないもの全部しまっちゃおうね   – PHP未使用の拡張   – chkconfig自動起動の不要サービス  

17:30   再起動テスト • 余裕があるうちに再起動をかける   – chkconfig  on  漏れ（ありがち１）   – sendmailが遅くて引っかかる（ありがち２）   • キャッシュあたためますか   – /var/lib/mysql  を  /dev/null  に放り込む   – curlでlocalhost叩いてOpcacheに放り込む  

17:55   あきらめる 祈る

18:00   試合終了 • 最終スコア：  88295点

心残り１   最後のボトルネック • サーバ性能を使い切れなかった   – 1台の時より負けてる   – サーバ間またぐレイテンシ分だけ損してる   – Varnish？MySQL？  

心残り２   残された不一致 • 一部のページで0.1%程度の不一致   – contentPage1〜4   – PURGEもしてるのでそんなに出ないはず   – 計測手法が非公表なので調査できず  

まとめ • PHP   – mod_php5(5.4)からphp-­‐fpm(5.5)に変更   – OPcacheを有効化   – 心なしかスピード凶寄りの設定 • Varnish • memcached • MySQL   – 5.6にアップグレード   – 心なしかスピード凶寄りの設定 • 小細工   – 監視等の全カット – 再起動後のキャッシュあたため

チューニングって楽しいよね！

宣伝 • 本だしました！   • クラウド時代の法律から   実装までの最適解を紹介   • hdp://goo.gl/BRY3Dt  [AA]   電子書籍版もあるよ！