DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
nginx最大パフォーマンスを出すための基本設定-オープンソーサー・日本
Nginxチューニング nginx最大限にスピードを出すために、設定パラメーターをチュニングしました。 nginx設定例 user www-data; pid /var/run/nginx.pid; worker_processes auto; worker_rlimit_nofile 100000; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; events { worker_connections 2048; multi_accept on; use epoll; } http { server_tokens off; sendfile on; tcp_nopush on; tcp_nodelay on; access_log o
MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ
もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました（と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです） 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその
プロファイリングで快適MySQLチューニング生活
MySQL 5.1からデフォルトで有効になっている便利な機能としてプロファイリングというものがある。MySQL 5.0でも利用出来たのだが、実験的な機能という位置づけであり、搭載されていたのはGPL版のMySQL Community Server限定だった。MySQL 5.1からは全てのエディションでプロファイリングを利用することができる。 プロファイリング機能を利用すると、クエリの状態（特に状態遷移やリソースの消費状況）を詳細に分析できるのでとても便利だ。MySQLエンジニア必携の機能といって良いだろう。というわけでプロファイリング機能の使い方を説明しよう。 MySQLサーバにログインしたら、まずは次のようにしてプロファイリングを有効にする。 mysql> SET profiling=1; すると、クエリの情報が記録されるようになる。次に、分析したいクエリを実行する。クエリはなんでもいい
第3回チューニンガソンに参加してきました。 - yokoninaritaiだけどその前にやることやります。
久しぶりのblogになります。 Zusaarでチューニンガソンの東京会場のページを見つけたときすでに、 参加者がいっぱいだったので諦めてましたが、 福岡でも開催されるとしり急いでエントリーしました。 当日の朝から開始まで 当日実は寝坊しそうで、会場到着はギリギリでした。 まーそんな中始まったチューニンガソンですが、 blojsomのチューニングが今回のお題でした。 えっとblojsomってなに？ tomcat + java ？？？ javaとかわかんないし、tomcatなんて使った事ないし。。。 ってところ始まりました。 まずは、blojsomがなんなのかgoogle先生に聞くところから始めました。 やったこと そんな感じで結果は6位でした。 これから簡単に僕がやった事を書いていきます。 まずやったのがMySQLのチューニング （っていうかこれで駄目ならもう無理って思ってました。） inn
FreeBSD kernel tuning
大規模サイトの為のFreeBSDカーネルチューニング (FreeBSD kernel tuning for large site) このコンテンツはもう古いです。考え方はそのままつかえるとおもいますが、よく吟味して、その時点の流儀で行ってください。 参考: [サーバー運用編]カーネル・チューニングをしてはいけない - ITエンジニアの「やってはいけない」：ITpro 文責: もりかわひろかず * ** 大規模なサービスを行うサーバOSとしておこなうべき チューニングの定石について記述します FreeBSDのバージョンは4.8-STABLEを対象にしています OSのデフォルト設定は一般的な規模を想定しています それを逸脱するような大規模な用途(大規模なwebサーバ、 web cache(squid)サーバ、バーチャルドメインサーバ[仮想サーバ])に使用するには、 やはりそれなりのチューニング
MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
チューニンガソン2で2位でした : DSAS開発者の部屋
10/1(土)にチューニンガソン2 というイベントに参加してきました。 もちろん前回に引き続き優勝を 目指していたのですが、今回は残念ながら2位でした。 今回もどんなチューニングをしていたのかの記録を公開します。 （ちなみに優勝したのは元KLabの濱野さんで、同じく メモを公開されています。） 今回のチューニンガソンのお題は、 Wikipedia の高速化で、 MediaWiki と Wikipedia の データが入った MySQL のデータには修正を加えずに、ランダムな100ページの表示速度を競いました。 マシンはメモリ1GBでデュアルコアのものが2台で、今回はWebサーバーの部分は自由に構成できます。 1. ボトルネックの確認 とりあえず AMI Linux の標準の php + apc で計測したところ、1ページの表示に1秒くらい使っています。 またphpか！ということで、やっぱり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Установка и настройка DNS сервера Unbound