運用してわかった Amazon RDS のパフォーマンスを上げる 3 つのコツ
本番環境で RDS を運用して数ヶ月。いろいろ試して RDS のパフォーマンスを上げるコツがわかってきたのでまとめたいと思います。 ここで取り上げるコツは以下を前提にしています。 データベースは PostgreSQL (Multi-AZ 配置) Read よりも Write が多い 夜間のバッチ処理がピーク 1 レコードは小さいが、一度に書き込むレコード数は多い アプリケーションの特性によっては当てはまらないこともあるでしょうし、他の RDBMS では結果が違ってくると思います。そこを踏まえたうえで参考にしてください。 Availability Zone はどちらかに寄せる RDS の Multi-AZ は耐障害性を上げるために欠かせない機能で、本番環境では Multi-AZ 配置が推奨されています。 Multi-AZ 配置にすると物理的に独立した AZ (Availability Zon
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
Slow Query Logでみるとこ - さよならインターネット
User@Host: kenjiskywalker[kenjiskywalker] @ localhost [] # Query_time: 0.00011111 Lock_time: 0.000099 Rows_sent: 1 Rows_examined: 300000000000000000000000 SET timestamp=999999999999; SELECT girl FROM girls_list WHERE name = 'homuhomu' みたいなスロークエリログがあったとして、 確認すべきところは Query_time = クエリの処理にかかった時間 Lock_time = ロックされた時間 Rows_sent = クエリにヒットしたレコード数 Rows_examined = 探索対象となったレコード数 で、ロックとかクエリにかかった時間は基本だと思うんですけど
Before Installing Fluentd | Fluentd
You MUST set up your environment according to the steps below before installing Fluentd. Failing to do so will be the cause of many unnecessary problems. Table of Contents Set Up NTP Increase Max # of File Descriptors Optimize Network Kernel Parameters Set Up NTP It’s HIGHLY recommended that you set up NTP daemon (e.g. chrony, ntpd, etc) on the node to have accurate current timestamp. This is cruc
Operations
Those instructions below are excerpts from the great Riak documentation. Please refer to the Open Files Limit and Kernel and Network Tuning sections for more details or for instructions for macOS. Gatling can consume a very large number of open file handles during normal operation. Typically, operating systems limit this number, so you may have to tweak a few options in your chosen OS so that you
TCP/IP で TIME_WAIT が残る時間を短くする
TIME_WAIT 状態の TCP コネクションが多数残る netstat コマンドで TCP コネクションの状態を確認していると、"TIME_WAIT" という状態のコネクションがたくさん確認される場合があります。 "TIME_WAIT" 状態というのは TCP コネクションにおいて、こちら側から通信をした場合に "FIN_WAIT_1" (FIN ACK 受信) から、"FIN_WAIT_2" (ACK 受信) または "CLOSING" (FIN 受信, ACK 送信)を経て、コネクションを閉じられる状態となったことを示すもののようです。 そしてこの "TIME_WAIT" から、実際にそのコネクションが閉じられて "CLOSED" となるまでの間に待ち時間があり、これによって、短時間に通信が集中すると、その分だけ通信終了間際の "TIME_WAIT" 状態のコネクションが多数、ne
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
