2010年3月12日金曜日

今さらながらdigの使い方

こんにちわ、おれ@花金仕事中です。
ウキウキしますねー。

今日はLinuxの「dig」コマンドについてメモです。
digコマンドは、DNSの正引き逆引きを行う超便利コマンドです。

例えばgoogle.co.jpの正引きをするには、
shell> dig google.co.jp

; <<>> DiG 9.2.4 <<>> google.co.jp
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38283
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.co.jp. IN A

;; ANSWER SECTION:
google.co.jp. 1800 IN A 72.14.203.104
google.co.jp. 1800 IN A 74.125.95.104
google.co.jp. 1800 IN A 74.125.91.104

;; Query time: 63 msec
;; SERVER: 192.168.60.1#53(192.168.60.1)
;; WHEN: Fri Mar 12 14:06:35 2010
;; MSG SIZE rcvd: 78
こんな感じです。
この「ANSWER SECTION」セクション内を見て
google.co.jpは、
72.14.203.104
74.125.95.104
74.125.91.104にヒモ付られているという事が分かります。

逆引きをする場合は「-x」オプションを付けます。
shell> dig -x 74.125.91.104


MXレコードやNSレコードを調べる場合は、
shell> dig google.co.jp mx
のようにtypeを指定します。
またネームサーバを指定する場合は、
shell> dig @a.dns.jp google.co.jp
のように「@(アットマーク)ネームサーバ」を指定します。


以上、でぇぇぇぇす。

2010年3月5日金曜日

rubyでASCII-8BIT~のエラーがでる

どうも、俺@仕事モヤモヤ中です。

rubyでWEBアプリを作っている(僕の環境の場合はUTF-8のアプリ)と
incompatible character encodings: ASCII-8BIT and UTF-8
とか
"\\xE3" from ASCII-8BIT to UTF-8...
Encoding::UndefinedConversionError
みたいなエラーが大量発生して泣きそうになっていました。

ログの通り、文字コードに関するエラーなのですが、だいたい
String.force_encoding("UTF-8")
で回避できます。

特に僕の場合は、sqlite3を使っていたのですが、
ruby-sqlite3モジュールでは、取得データを全てASCII-8BITで保持する実装になっているようで、
Rubyで遊ぶよ Rubyのsqlite3-rubyは必ず文字コードASCII-8BITとして返す
ASCIIなバイト文字列をUTF-8にする際におかしなコードに引っかかっちゃってる系でエラーが出るようです。

ruby-sqlite3の場合は、取得したデータをことごとく .force_encoding("UTF-8")すれば何とかなります。


ちなみに、rubyで文字コード対策としてマジックコメントというものがあります。
#!/usr/local/bin/ruby
# -*- coding: utf-8 -*-
とすれば、文字コードを判別して出力してくれます。


以上どえぇぇぇぇす。

2010年3月2日火曜日

MySQL 実行中のスレッドをリアルタイム表示

どうも、俺@仕事中です。

今日はMySQLで実行中のスレッドを表示するコマンドの紹介です。
mysql> show processlist;
+---------+-------+-------------------+---------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+---------+-------+-------------------+---------+---------+------+-------+------------------+
| 4416652 | mysql | xx.xxx.x.xx:54924 | dbname | Sleep | 361 | | NULL |
| 4470098 | mysql | xx.xxx.x.xx:35214 | dbname | Sleep | 6 | | NULL |
| 4470608 | root | localhost | NULL | Query | 0 | NULL | show processlist |
+---------+-------+-------------------+---------+---------+------+-------+------------------+
です。

詳しくは、My SQL 5.1 リファレンスマニュアル

2010年3月1日月曜日

MySQLで「Too many connections」のエラー

どうも、俺@週明け仕事中です。

週末、とあるシステムでMySQLの「Too many connections」が多発する障害が発生しました。
その時調べたメモです。

このエラーは、「コネクションの数が多すぎてもう接続できないよー」というものです。
MySQLの設定は
mysql> show global variables like '%max_connection%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 100 |
+-----------------+-------+
という状態です。
デフォルト値が「100」なのだそうで、まず単純にコネクション最大数を増やします。
mysql> set global max_connections = 256;
コネクション数が増えるので、CPU負荷とメモリ使用量に注意が必要です。

他に注目すべきは、
mysql> show status like '%threads_%';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| Threads_cached | 6 |
| Threads_connected | 4 |
| Threads_created | 140909 |
| Threads_running | 3 |
+------------------------+--------+
うわー!エラいことなっとる!
ここの項目の見方は、
Threads_cached ... スレッドキャッシュでキャッシュされているスレッドの数。
Threads_connected ... 現在生成されているスレッドの数。
Threads_created ... 起動してから生成されたスレッドの数。この値が大きい場合はthread_cache_sizeの値を大きくした方が良いかも。
Threads_running ... 現在動作中のスレッド数。

と言うわけで、今回の件ではthread_cache_sizeの値を増やしておきます。
mysql> set global thread_cache_size = 64;
と、共にwait_timeoutの状況をチェック。
mysql> show global variables like 'wait_timeout%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| wait_timeout | 28800 |
+--------------------------+-------+
28800秒、つまり8時間に設定されているので、もう少し縮めて起きます。
mysql> set global wait_timeout = 3600;
1時間にしました。
wait_timeoutは接続があってスレッドが生成され待機状態(アイドル状態)になって○秒経過したら接続を切るというもの。
mysql_pconnect()やPDOでの持続的接続とかでも、wait_timeout秒数経過すると切断されます。(と、思う、、)
ちなみに、wait_timeouをmy.cnfに設定する場合は、
# vim /etc/my.cnf
set-variable = wait_timeout = 3600
のようにするらしい。


また経過監視します。以上どぇぇす。