nginxのパフォーマンスチューニング@shibuya.pm#17
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
クエリキャッシュは切ったほうがいいんじゃなイカ？ : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
MySQLTunerでMySQLのチューニングを診断する方法
https://github.com/rackerhacker/MySQLTuner-perl MySQLTunerはMySQLのチューニングを診断してくれるアプリケーションです。 基本的なパフォーマンスチューニングのヒントをわかりやすく表示してくれます。 MySQLのチューニング設定に不安な方や、はじめてMySQLをさわる方は試してみると良いでしょう。 ライセンスはGNU GPLで無料で使えます。 検証環境 CentOS 6.3(64bit) MySQL 5.5.28 MySQL 5.5をインストール MySQL 5.5をインストールします。 # wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm # wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86
MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)
バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5
KOSHIGOE学習帳 - [MySQL] パフォーマンス関連メモ
{{toc_here}} InnoDB パフォーマンスチューニング MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11 InnoDB パフォーマンス チューニング ヒント MySQL :: MySQL 5.1 Reference Manual :: 13.6.13.1 InnoDB Performance Tuning Tips 長過ぎる PRIMARY KEY を避けてディスク領域の無駄遣いを避ける セカンダリインデックス用に余計な領域を使わないよう、長い主キーを避ける 主キーが長い場合、代わりに AUTO_INCREMENT なカラムを主キーとして作成するとよい 補足 MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.13 InnoDB テーブルとインデックス構造 MySQL :: MySQL 5.1 Reference Ma
MySQLのメモリ設定を追求してみよう – OpenGroove
（2015年1月追記：これは現時点で約5年前に書いた記事です。各種パラメータは名称や仕様が変更されている可能性があるため、最新の情報を参考にしてください） MySQLのメモリの話を考えていたら何が何だか分からなくなってきたので、my.cnfでの設定に絡めてまとめてみようと思う。そもそも、MySQLサーバにおいてMySQLのプロセスがトータルで使用するメモリは、どれくらいに見積もっておけばいいだろうか。参考書やネット上では以下のような計算式が紹介されている。 max_connections x [スレッド領域用メモリ合計値] に、以下をプラス。 [グローバル領域用メモリ合計値] DB専用サーバの場合だとこの値をマシン搭載メモリの8〜9割くらいにする、と想定するのがひとつの指針となるようだ。しかし32bit版Linux OSの場合は2〜3GBまでの制限があるため、搭載メモリがそれ以上あったとし
ローカルポートを食いつぶしていた話 - download_takeshi’s diary
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 （このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・） で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ
というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日（火）の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日（水）12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根本的に間違っているのだろうか？それとも、もうGIGAZINEサーバのハード
GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 ＠IT：Apacheパフォーマンス・チューニングの実践（1/2） この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソーシャルゲームスケールアウトの歴史
MySQL 初めてのチューニング