タグ

@MySQLに関するtoteriのブックマーク (46)

  • このページを見るには、ログインまたは登録してください

    Facebookで投稿や写真などをチェックできます。

    toteri
    toteri 2011/08/22
    サービス停止することなくALTER TABLEする![@PHP]
  • http://mysql-casual.org/2011/08/mysql-casual-talks-vol2-1.html

  • GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法

    ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 @IT:Apacheパフォーマンス・チューニングの実践(1/2) この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA

    GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
  • 『[PGメモ]シーケンス(っぽい)DBを作成してAUTO_INCREMENT的にID管理を行う』

    Late Riserダメ主婦ミルミルのプログラムと道の駅ドライブとリラックマの日々。 プログラム系は情報提供ではなく個人的メモなので、信憑性薄め。 検証version: 5.0.67-community-log MySQL Community Edition (GPL) MtSQL5.1からは高性能化したAUTO_INCREMENTですが、 やはり旧バージョンではロックがネックとなり、マルチタスクには対応が微妙な模様。 こいつに対する処理方法についての検証として、 MyISAMテーブルを用いたシーケンス(的)管理方法の動作検証を簡単にしてみた。 とりあえず、下記のようなテーブルをつくる。 一つはスタック用のテーブル。もう一つはシーケンス用。 トランザクションの範囲外で動いているシーケンスのIDを都度取得し、 test_stackのstack_idに連動させればよいのではないかと。 CREA

    toteri
    toteri 2010/11/17
    auto_incrementが競合しないように、シーケンステーブル作ってIDを明示的に管理する
  • ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering

    こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL

    ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
    toteri
    toteri 2010/11/16
    パーティション、Sharding周りを参考にする
  • 現場指向のレプリケーション詳説

    この文書は、技術評論社刊『WEB+DB PRESS Vol.22』に執筆した記事を技術評論社の 許可を得てWWWで公開しているものです。 このWWW版は校正前の原稿を元にしている点、WWW公開後に必要があれば修正する点で、雑誌版の文章とは異なる部分があります。また、図表も雑誌版とは異なります。 予めご了承ください。 また、この文章が対象しているのはMySQL 4.0系なので、最新のリリース版と比べると説明不足な点などが多々あると思います。 レプリケーションの基をおさえるには、この文書はまだ有益だと思いますが、設定レベルの説明は最新のドキュメントを参照するようにしてください。

    toteri
    toteri 2010/11/09
    スレーブのSQLスレッドが停止してたので参考にさせて頂いた。
  • MySQLの重さの原因はDNS逆引きだった – netcreates. blog

    昨日、私的に運用しているサーバのMySQLが急に重くなり、connectできないという現象に陥りました。 原因を探ったところ、ファイアウォール側の問題でサーバからDNSの逆引きができない状態になっていて、MySQLDNSサーバの応答をずっと待っていたためプロセス数が最大になってしまった模様。 DNS逆引きができるようになると何事も無かったかのようにMySQLが軽くなりました。 http://dev.mysql.com/doc/refman/4.1/ja/dns.html を見ると、「–skip-name-resolve を mysqld オプションを指定して起動すると、DNS ホスト名ルックアップを無効化できます。ただし、この場合は、MySQL 権限テーブルで IP 番号しか使用できなくなります。」と書いてあるため、早速my.cnfに下記の設定を追加しました。 [mysqld] skip

    MySQLの重さの原因はDNS逆引きだった – netcreates. blog
    toteri
    toteri 2010/11/04
    show processlistで「unauthenticated user」が出た場合の解決法。ただし、IP直指定の場合に限る。
  • InnoDBのファイルサイズ管理

    最近、InnoDBのデータ領域(テーブルスペース)が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。(ここのところMySQLネタが続いているが、Planet MySQL語版を意識しているわけではないのであしからず!!<<ホントかよ?!>俺) InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切

    InnoDBのファイルサイズ管理
    toteri
    toteri 2010/10/29
    ”innodb_file_per_tableの設定をしておくと…テーブルスペースが大きくなってしまってからでもテーブルを削除すればファイルシステムの空き領域を増やすことが可能になる”
  • http://fine.ap.teacup.com/hepo/47.html

  • MySQL バイナリログの削除 - とみぞーノート

    1. 概要 MySQLでレプリケーションを行っているとMasterにバイナリログが溜っていきディスクを圧迫するので定期的に削除してやる必要がある。 2. 手順 2.1 レプリケーション状態の確認 まず、どこまでバイナリログを削除してよいかを調べる。 Slave側でSHOW SLAVE STATUSを実行し、Slaveがバイナリログをどこまで読み取っているかを調べる。「Master_Log_File」が現在参照中のバイナリログ。以下の例ではskylancer00-bin.000084を使用していることになるので、skylancer00-bin.000083まで削除してしまってよいことになる。Slaveが複数いる場合は、全Slaveについて確認を行う。 mysql> SHOW SLAVE STATUS \G *************************** 1. row ********

  • MySQLのパフォーマンスチューニング - モノノフ日記

    とある勉強会でSunのエンジニアの人のプレゼンを直接聞く機会があったのでメモったことを公開します。基的な事が多いんだろうけど、非常に参考になりました。 パフォーマンスとは スループット レスポンスタイム/レイテンシ スケーラビリティ 上記のコンビネーション アーキテクチャとは Connection Thread Pool Query Cache Parser SQLクエリをパース Optimizer Storage Engines アプリによって最適なエンジンを選択すべき サーバのコネクション&スレッド my.cnf max_connection (100) 多すぎるとメモリを消費しきる可能性あり thread_cache_size (8) スレッドをコネクションの切断後にもキャッシュしておく数 一般的には max_connections / 3 sort_buffer_size(2M)

    MySQLのパフォーマンスチューニング - モノノフ日記
  • MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記

    MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。日はそれを無停止、オンラインのままでできないかという話題です。 基的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう

    MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記
    toteri
    toteri 2010/10/19
    実際に使うかわからないけど、心にとどめておこう。
  • サブクエリーにLIMITを使った履歴系テーブルの高速化(MySQLでマテリアライズドビュー3 番外編) - イノベートな非日常

    履歴系テーブルは基的にページャーでページ分割することがほとんどだと思います。前回のエントリーでもLIMIT句を使って30行だけ取ってきている例となっています。今回の問題点は、巨大なテーブル×巨大なテーブルのJOINをしようとするから重いのであって、予めどちらか一方のテーブルのデータを絞っておけば相当早くなるはずです。そこで、大となるcommentテーブルで先にLIMITをかけてしまいます。 SELECT SQL_NO_CACHE comment_id , fu.user_name form_user_name , tu.user_name to_user_name , comment FROM (SELECT * FROM `comment` LIMIT 900000,30) cm,user fu,user tu WHERE fu.user_id=cm.from_user_id AND

    サブクエリーにLIMITを使った履歴系テーブルの高速化(MySQLでマテリアライズドビュー3 番外編) - イノベートな非日常
    toteri
    toteri 2010/10/04
    JOIN時のSQL高速化など
  • [MySQL]ORDER BY RAND()について - かけだしエンジニアの独り言

    2008年10月15日 15:13 カテゴリMySQL [MySQL]ORDER BY RAND()について Posted by kistame228 No Comments No Trackbacks Tweet MySQLのORDER BY RANDはランダムに値を取得してくれる 便利なのだけど、RANDを利用すると全文走査するので 大きなテーブルだと非常に重くなってしまう。 で、見つけたのが以下のAntonさんのブログ ◆“Do not use ORDER BY RAND()” or “How to get random rows from table?” ↑をザックリ訳してみると ・RANDは使うな ・じゃぁどうするのか 1-1.SELECT COUNT(*) AS cnt FROM quotes で全件数を取得 1-2.1-1で取得した数値からランダムな値をプログラムで生成 1-

    toteri
    toteri 2010/10/04
    復習。[パフォーマンス]
  • @IT Special PR:600億PVもMySQLで! モバゲーのインフラ底力

    携帯向けサイト「モバゲータウン」の勢いが止まらない。2010年3月の会員数は約1800万人、月間ページビュー(PV)600億という"モンスターSNS"に成長している。意外なことに、これだけのアクセスをさばくのに、memcachedをはじめとするKVS(Key-Value Store)系のインフラ・ソフトはあまり使っておらず、MySQLで十分だという。モバゲータウンのインフラ担当者に話を聞いた。 モバゲータウンを運営するDeNA(ディー・エヌ・エー)は、もともと1999年に開始したオークションサイト「ビッダーズ」で知られている。その後、オークションに加えてECサイトを開始し、auとの提携により「auショッピングモール」などで急速に成長した。 ビッダーズだけでも、数千万PV規模の大規模サービスだが、最近はモバゲータウンの成長が著しい。 「特に2009年9月から順次リリースした自社製のソーシャル

  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

  • DTraceによるMySQL解析ことはじめ

    Webなどで人気の高いMySQLデータベースサーバーにおいて、DTraceを使った解析手法を紹介します。MySQLの構造的について簡単にお話しし、それをどのようにDTraceで追いかけるかについて説明します。Read less

    DTraceによるMySQL解析ことはじめ
  • 「エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド」発刊のおしらせ。

    来たる6月12日、我が入魂の書籍が発刊される運びとなった。執筆を開始したのはすでに一年以上前であり、ブログでも何度か「執筆中です!」といいながらなかなか発刊に至らずお待たせしてしまったのだが、しかし時間がかかってしまった分、内容には磨きがかかったと思うので期待して頂きたい。書籍のタイトルは「エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド」。筆者にとって初の著書(単著)である。名前にエキスパートと冠している通り、中級〜上級者向けの一冊となっている。初心者の方は、まずMySQL 徹底入門 第2版などを先に読んでから書を購入するといいだろう。以下もくじである。 第1章 MySQLの概要 1 MySQLとは 1-1 世界で最も有名なオープンソースのRDBMS 1-2 LAMPの"M" 1-3 History 2 MySQL Serverの種類 2-1 FOSS Exc

    「エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド」発刊のおしらせ。
  • MySQLのrootユーザを削除してしまいました 質問と回答(Q&A) [okyuu.com]

  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

    InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い(テーブルの行数を保持してる)のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ

    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
    toteri
    toteri 2010/03/29
    "セカンダリインデックス"以降が必見!