元スレMySQL 総合 Part15

mysql覧 / PC版 /

みんなの評価 : ☆

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

51 = :

関数つくればいいんじゃね？

52 = :

MySQL5の限界を上げたいのですが、どこをチューニングしればいいのか教えてください。
基本的なチューニングは出来てると思います。

サーバーは、DB専用で4CPU　メモリ8GB

max_connections 許容接続数 2000 本
Max_used_connections 過去発生した最大接続数 916 本
（mysql接続のみの数字）

916本で、MySQLに接続が出来なくなってしまいます。
これを2000まで持って行きたいのです。

CPUやメモリは、余裕があります。

アドバイスを下さい。神様。

54 = :

そうですよね。。
OSはdebian Etch 64bit
Linux db 2.6.18-6-amd64 #1 SMP Fri Oct 10 05:11:18 UTC 2008 x86_64 GNU/Linux

サーバー側:MySQL5.0.32-Debian_7etch8-log
クライアント側：MySQL5.0.32

エラーは出てないですが、WEBサーバーから接続が出来なくなってしまいます。
しばらくしたら、接続出来るようになるのですが・・。

まず、MySQLへの接続なしで、負荷ツールで負荷をかけても問題なく処理されるのですが、
MySQLへの接続をすると、しばらくして接続が出来なくなります。

Apache2とMySQL5のサーバーは物理的に分かれています。

55 = :

max_connectionsを増やすときは、open_files_limitも増やす必要がある。

sql/mysqld.cc
static int init_common_variables(
～
　max_open_files= max(max(wanted_files, max_connections*5), open_files_　
　files= my_set_max_open_files(max_open_files);
　/* ↑ここでulimitのopen files制限に引っかかるなどしてしまうと */
　if (files < wanted_files) {
　　if (!open_files_limit) {
　　　max_connections= (ulong) min(files-10-TABLE_OPEN_CACHE_MIN*2, max_connections);
　　　/* ↑ ここでmax_connectionsを減らされてしまう。

mysqldのログでこんなのが出てないかも確認してみて。
[Warning] Changed limits: max_open_files: 1024 max_connections: 886 table_cache: 64

でもデータベースに900接続って時点でわりと異常なので
アプリケーションがきちんと切断してるかも確認してください。

56 = :

ありがとうございます。

早速、ログを見てみましたけど、何も吐き出されてませんでした。

負荷ツールを使ってデータを取ってみたのですが、下記のコマンドで1800まで行って、実際にDBへ繋げたのが140まで下がってきた所でした。
#netstat -an | wc -l　
1800

もしかして、何か根本的におかしいのかな。

アプリ側では、明示的に切断はしてませんが、、スクリプトが終われば、勝手に切断されるんですよね？？
PHPとPDOで接続しています。

あと、よく分かりませんが、
Max_used_connections 過去発生した最大接続数 1786 本まで行きました。
けど、ページが表示されない・・待ちの状態で、DB接続出来なくタイムアウトに。

なんでしょうね・・。

57 = :

色々調べてみましたが、netstat -anのコマンドで見てみると「ESTABLISHED」だらけになってました。

#netstat -an | wc -l　で　140以下になればうまく接続出来るようです。

58 = :

linux同士でレプリケーションをしているときに、
cronで同期ができているかどうかをチェックするにはどのようにすればいいでしょうか？
レプリケーションができているかどうかを
シェルスクリプトから確認するにはどのように行えばいいでしょうか？

59 = :

自己レスです

>>56
WEBサーバーからDBサーバーへ接続が出来ないときでも、
DBサーバーからMySQLへアクセスする事が出来ました。

恐らく、ネットワーク周りが原因なのかなぁと。

62 = :

AUTO_INCREMENTでPRIYMARY KEYである行（行の名前はid）を追加するSQLを
下記のように組みました。

alter table input add column input int PRIYMARY KEY(id) AUTO_INCREMENT;

上記だとエラーだとになります。どこがおかしいのでしょうか？
ぐぐってみてもわからないので質問させていただきました。ご教授頂ければ
幸いです。

66 = :

[mysqld]
character_set_server = utf8

[client]
default_character_set = cp932

ねんのため一回データベースとテーブルつくりなおしてみて。

68 = :

スロークエリを吐くこと自体の負荷は
100MBのファイルに100バイト追記するのも
1KBのファイルに100バイト追記するのも変わらんよ。

それはおいといて、
スロークエリログが100MBも出るってことは
そもそもチューニングされてないってことだよね。
そのデータベースは遅いだろうね。

69 = :

>68
ありがとうございます。
となると、150MBのslow.logを消した昨日辺りから妙に動作が軽いのは
ログのサイズには無関係か……

＞100MBも出るってことは
ですよねぇ。

パソコンに詳しいからと言う理由で唐突にサーバ管理を任されてしまい
どこからメンテナンスすればいいものか……。

70 = :

どなたかお助けください。

max_allowed_packetを4Mにセットした上で、マルチプルインサートを使って
9000件程度のデータを4MB弱のSQL文にまとめて実行しているのですが
Packets larger than max_allowed_packet are not allowed.エラーが
出てしまいます。

登録すべきデータ件数が多いので、出来るだけまとめて登録したいのですが
SQL文が実際にはどのくらいのパケットサイズになるかを見積もるには
どうすればよいのでしょうか？　どこまで削れば通るのか皆目見当がつかないもので…orz

72 = :

>>71
ご指摘ありがとうございます。データ総数が100万件を軽く超えるので
少しでも高速化するため、プログラム内でmax_allowed_packet値を取得して、
それと見比べながらSQL文を構築、限界まで伸ばしてから実行、という
手順を取っています。全件つなげても流石に100MBは行かないと思いますが
限られた範囲で頑張れたらなぁ、と。わがままなのですが。

なお、SQL文を短くするほうで試してみましたところ、
9215件分の 3,825,253byte のSQL文は通りましたが、
9425件分の 3,911,372byte はだめでした。max 4,194,304byte に対して
300KB近くの余裕が必要ということで、MySQL内部での処理時には1件毎に
何らかのヘッダが付いて処理されていると推測しています（流石にSQL
1文に300KBは無いと)。で、そのヘッダサイズが分かれば解決！と
思っているのですが、そもそもこの考えが正しいのか皆目見当が付きません。
MySQL内部でのパケット構造はググってもなかなか見つからないもので
引き続きお知恵をお貸しいただければ幸いです。

73 = :

そこまでするなら、パケットダンプして確認してみたら？

75 = :

76 = :

sourceコマンドで大量のinsert文を入れてるんだけど
１行目だけ必ずエラーが出る
その１行目を手動で入れるとエラーは出ない
２行目以降は全て正常に入る

なんだろう？
UTF-8に統一しててエンコード問題でもないと思うんだけど

78 = :

>>75
SQLモードによるんだそうだ。
http://dev.mysql.com/doc/refman/5.1/ja/data-type-defaults.html

>>76
BOMがついてるとか？
ためしてないけど

79 = :

>>78
ありがとうございます。
どの環境でも同じように使うには、
面倒ですが、デフォルト値は明示したほうがよさそうですね。

80 = :

develとかserverとかclientとかあるけど具体的な違いってなんなの？

81 = :

>>80
名前の通り。そのまんまの用途だと気づけ。

82 = :

用途の違いは分かるけど具体的な機能の違いはなんなの？って聞いてるの

83 = :

全文検索で、特定のレコードだけインデックスしないって出来る？

84 = :

>>82
clientはサーバになれないし、develがないと MySQL ライブラリを使用するプログラムをコンパイルできない。

MySQL全体を用途毎にわけただけ。

85 = :

mysql5.01のバッチモードにて、あるテーブルに条件にあるデータが入っていた場合、後続バッチを強制中止させたいのですが。
select 1/count(*) from hoge;
として、レコード0の場合もエラーになりません・・・
set session sql_mode='STRICT_ALL_TABLES';も、insert/updateにしか0除算エラーにしてくれないらしく困っています。

なにかselectでエラーとして中止させる良い方法は無いでしょうか。

86 = :

>>85
http://forums.mysql.com/read.php?99,55108,55108#msg-55108
なんかUDFつかえとかちょっとトリッキーみたい。
素直にストアド書くか、C/Perl/Javaとかで書いたほうがよさそう？

87 = :

>>86
ユーザ定義関数からraiseですか。
割とどんな事でもクエリが落ちない仕様っていうのは、mysqlの利点にもなってるのでしょうね・・・

>素直にストアド書くか、C/Perl/Javaとかで書いたほうがよさそう？

ですねぇ。
ありがとうございました。

88 = :

これはどういう意味？組み合わせアルゴリズムってjoinの事？

http://dev.mysql.com/doc/refman/5.1/ja/view-restrictions.html
組合せアルゴリズムを使用して処理されたビューに、
インデックスを使うことは可能です。
しかし、誘導可能なアルゴリズムで処理されたビューは、
その背後にあるテーブルのインデックスを活用することができません
( 一時テーブルの作成中にインデックスを使用することはできます ) 。

89 = :

index関係調べてるとmysqlなんて使うべきじゃなかったと後悔するな・・・

90 = :

userテーブルにprofileフィールドやareaフィールドやcategoryフィールドがあったとして
３つ全て別のテーブルへの参照だったとする
この場合、それら３つのフィールドへの全文検索を行うにはどうするか？

正規化したらindex使えなくなるとか無いだろ・・・
他のRDBMSはビューに対してインデックス張れたり
オプティマイザがもっと賢かったりインデックスが強力だったり
こういうところで躓かない高機能さがある

91 = :

たぶん最善案はprofile,area,category全部に個別に全文インデックス張って
３つサブクエリ発行して積集合を求める方法
他のRDBMSの３倍＋α（積集合負荷）の処理時間になりそう

あー

92 = :

>>91の方法でもクエリされたキーワード（AND）全部含んでないと該当しないから
結局複数テーブル間の検索は出来ないわｗ

おわった

93 = :

積集合じゃなくて和集合じゃないか？
オプティマイザがタコいのには狂おしいほど同意するけど

94 = :

と言うか、結合後のテーブルに対してインデックス出来ないとダメ
テーブルをまたいだインデックスを張れるか、
ビューに対してインデックスを張れないといけない
MySQLには探したところそういった機能は無い（代替になるようなものも）

正規化を崩してパフォーマンスを求める場合がある、と言われる典型的な例だと思う。
MySQLではareaテーブルとか作っちゃいけないんだよ。

95 = :

昔からある問題のはずなのに未だ解決されてないところを見ると
MySQL自体使わないほうが良いと思ったわ
開発停滞してるだろこれ

96 = :

新機能の不具合が多すぎて
パフォーマンスまで手が回ってないんだよ。

97 = :

MySQLって確かC言語（笑）で実装されてるよね
そりゃ開発も停滞するわ
そんなもん普及させるなよな・・・

98 = :

いや、Cなら普通では。PostgreSQLもCですよ？

MySQLはCとC++のハイブリッド。
ソースを見てグローバル変数のすさまじい数に絶望するといいよ！

100 = :

できた

mysql> update q99 set col2 = (select ename from emp where empno = 7788);
Query OK, 1 row affected (0.15 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from q99;
+------+-------+
| col1 | col2 |
+------+-------+
| 1 | scott |
+------+-------+
1 row in set (0.00 sec)

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで /

mysql一覧へ

みんなの評価 : ☆

類似してるかもしれないスレッド

MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○

トップメニューへ / →のくす牧場書庫について

総計:	127,062,755人
頁
昨日:	no data人
頁
今日:	人
頁