このブログを検索

2011年3月2日水曜日

Linuxのメモリ割り当て状況を確認する

$ LANG=C sar -R
実行結果は次の通り。
campgが負の値になるとキャッシュがあまり効いていません。
frmpg/s  ・・・  解放されたメモリのページ数/s
bufpg/s  ・・・  割り当てられたバッファのページ数/s
campg/s  ・・・  キャッシュしたページ数/s

00:00:01      frmpg/s   bufpg/s   campg/s
00:01:01      -604.87      0.17      0.08
00:02:01       312.58      0.13      0.05
00:03:01        -3.60      0.22      0.18
00:04:01      -192.49      0.27      0.10
00:05:01        22.62     -1.25    -40.25
00:06:01         6.82      0.23      0.00

2011年2月24日木曜日

[PHP]バージョンを見えないようにする

PHPの場合、Apacheのバージョンを見えなくするをした上で、さらにPHPの設定を変更します。

php.iniを次のように変更します。
expose_php = Off

●変更前
$ telnet sssdev1 80
Trying 192.xxx.xxx.xxx...
Connected to sssdev1.sss.indexweb.co.jp (192.xxx.xxx.xxx).
Escape character is '^]'.
GET /pinfo.php HTTP/1.1
Host: ssssfuka.indexweb.co.jp

HTTP/1.1 200 OK
Date: Thu, 24 Feb 2011 03:09:46 GMT
Server: Apache
ココ→★X-Powered-By: PHP/5.2.17
Transfer-Encoding: chunked
Content-Type: text/html
        :
●設定後
$ telnet sssdev1 80
Trying 192.xxx.xxx.xxx...
Connected to sssdev1.sss.indexweb.co.jp (192.xxx.xxx.xxx).
Escape character is '^]'.
GET /pinfo.php HTTP/1.1
Host: ssssfuka.indexweb.co.jp

HTTP/1.1 200 OK
Date: Thu, 24 Feb 2011 03:11:17 GMT
Server: Apache
★(表示されない)
Transfer-Encoding: chunked
Content-Type: text/html
        :

[Apache]バージョンを見えないようにする

Apacheのバージョンが見えるとセキュリティ上、問題があります。
例えば、そのバージョンにあるセキュリティホールを使われてしまうリスクがあるためです。
詳細はこちら。
http://httpd.apache.org/docs/2.2/ja/mod/core.html#servertokens

httpd.confに次のように記述します。
ServerTokens ProductOnly
●変更前
$ telnet sssdev1 80
Trying 172.xxx.xxx.xxx...
Connected to sssdev1.sss.indexweb.co.jp (172.xxx.xxx.xxx).
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 400 Bad Request
Date: Thu, 24 Feb 2011 01:08:00 GMT
ココ→★Server: Apache/2.2.1x (Unix) DAV/2 PHP/5.2.1x
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
       :
●設定後
$ telnet sssdev1 80
Trying 172.xxx.xxx.xxx...
Connected to sssdev1.sss.indexweb.co.jp (172.xxx.xxx.xxx).
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 400 Bad Request
Date: Thu, 24 Feb 2011 01:08:57 GMT
ココ→★Server: Apache
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
       :

2011年2月23日水曜日

SSL証明書をopensslコマンドで確認する

opensslコマンドで接続先の証明書を取得することができます。
$ openssl s_client -connect xx.xx.xxx.xxx:443 -showcerts

-showcertsは、ベリサインなどの中間証明書も取得したい場合に使います。
ベリサインだけではないでしょうが、CAはときどき証明書の構成や暗号ロジックを変更することがあります。
実行例は次の通り。
CONNECTED(00000003)
depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
verify return:1
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server 1024-bit CA - G2
verify return:1
depth=0 /C=JP/ST=Tokyo/L=Taishido, Setagaya-ku/O=Index Corporation/OU=Technical Support Dept./CN=ssl-ssss.indexweb.co.jp
verify return:1
---
Certificate chain
 0 s:/C=JP/ST=Tokyo/L=Taishido, Setagaya-ku/O=Index Corporation/OU=Technical Support Dept./CN=ssl-ssss.indexweb.co.jp
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server 1024-bit CA - G2
-----BEGIN CERTIFICATE-----   ★接続先の証明書
MIIeWZccbcYGaWibaGiqywYoY9B7krqf1Jf92VXf4danbGKQHKIg9W0baqUFADCB
             :
+zcHSBcs/TAf0SUFoYTaaYS/pzeJUhO=
-----END CERTIFICATE-----
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server 1024-bit CA - G2
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
-----BEGIN CERTIFICATE-----   ★ベリサインの中間証明書
MIIfRdccbrwGaWibaGiqzwzyZf3KeK/Wf+X7KrvLGdanbGKQHKIg9W0baqufadCB
             :
54aOnkweIl2+DoyLE39vHw==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=JP/ST=Tokyo/L=Taishido, Setagaya-ku/O=Index Corporation/OU=Technical Support Dept./CN=ssl-ssss.indexweb.co.jp
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server 1024-bit CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 2844 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    Session-ID-ctx: 
    Master-Key: XXXXXXXXXXXXXXXXXXXXXXX
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1298440296
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
取得した証明書の内容を確認するのもopensslコマンドを使います。
コモンネームだけ知りたければgrepすると簡単です。
$ openssl asn1parse -i -in test.crt | grep -A1 commonName
  185:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  190:d=5  hl=2 l=  47 prim:      PRINTABLESTRING   :VeriSign Class 3 Secure Server 1024-bit CA - G2
--
  401:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  406:d=5  hl=2 l=  23 prim:      T61STRING         :ssl-ssss.indexweb.co.jp

2011年2月15日火曜日

[CloudForecast]RRDファイルへDSを追加する

RRDファイルへのData Sourceを追加する
基本的にRRDファイルはDS(Data Source)の追加ができません。
※そのため、CactiではRRD管理をグラフ単位にしています。
追加は、RRDファイルからdumpしたXMLファイルを修正してRRDにrestoreします。

1.RRDファイルのXML出力
$ rrdtool dump MONSSS_perfstat-xxxxxx.rrd xml/new.xml
2.XMLへDS追加
このperlスクリプトが便利です。
http://osdir.com/ml/db.rrdtool.user/2003-08/msg00116.html
perl rrdaddds.pl xml/new.xml DS名 > xml/new2.xml
3.DSタイプの修正
前述のスクリプトは強制的にDSタイプをGAUGEに設定します。
それ以外のDSタイプにする場合は、viなどエディタで修正します。
4.RRDファイルにリストア
$ rrdtool restore xml/new2.xml MONSSS_perfstat-xxxxxx.rrd

[MySQL]InnoDBのステータスを確認する

InnoDBのステータスを確認します。
この例では、InnoDB Pluginを使っているので、I/Oスレッド(read/write)をそれぞれ4に増やしてます。
$ grep _io_threads /etc/my.cnf
innodb_read_io_threads=4
innodb_write_io_threads=4

$ mysql -u root -p
mysql> SHOW ENGINE INNODB STATUS;
| Type   | Name | Status| InnoDB |      | 
=====================================
110215 22:32:10 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 8 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 20844 1_second, 20844 sleeps, 1732 10_second, 3540 background, 3540 flush
srv_master_thread log flush and writes: 20914
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 832, signal count 830
Mutex spin waits 234, rounds 6018, OS waits 63
RW-shared spins 763, OS waits 763; RW-excl spins 0, OS waits 6
Spin rounds per wait: 25.72 mutex, 30.00 RW-shared, 180.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 417D3
Purge done for trx's n:o < 417C3 undo n:o < 0
History list length 7
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started, process no 3139, OS thread id 1242859840
MySQL thread id 5425, query id 65466 localhost root
SHOW ENGINE INNODB STATUS
---TRANSACTION 417D2, not started, process no 3139, OS thread id 1103010112
MySQL thread id 5422, query id 65451 Has read all relay log; waiting for the slave I/O thread to update it
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
523 OS file reads, 9909 OS file writes, 8774 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 6375023, node heap has 4 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 177701418
Log flushed up to   177701418
Last checkpoint at  177701418
0 pending log writes, 0 pending chkp writes
5225 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 3293577216; in additional pool allocated 0
Dictionary memory allocated 607926
Buffer pool size   196607
Free buffers       194357
Database pages     2246
Old database pages 832
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 486, created 4563, written 7861
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s
LRU len: 2246, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 3139, id 1211124032, state: waiting for server activity
Number of rows inserted 514325, updated 8978, deleted 109, read 9934992
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

2011年2月10日木曜日

[MySQL]Maatkitによりレプリケーションの整合性をチェックする

何かしらの事情でマスタとスレーブに差異が出ることがあります。
マスタ、スレーブともにテーブルロックして比較するのが正攻法ですが、サービスに必ず影響が出ます。
そこで、Maatkitでチェックします。

1.しくみ
テーブルのチェックサム情報をマスタにinsertします。
ステートメントベースでスレーブに転送されるので、スレーブ側に差異があればマスタと異なるチェックサムが記録されます。

2.チェックサム記録用テーブルの作成
SQL> use mysql;
SQL> CREATE TABLE checksum (
     db         char(64)     NOT NULL,
     tbl        char(64)     NOT NULL,
     chunk      int          NOT NULL,
     boundaries char(100)    NOT NULL,
     this_crc   char(40)     NOT NULL,
     this_cnt   int          NOT NULL,
     master_crc char(40)         NULL,
     master_cnt int              NULL,
     ts         timestamp    NOT NULL,
     PRIMARY KEY (db, tbl, chunk)
  );

3.スレーブ→マスタ権限追加

4.チェックサムの記録
スレーブから実行します。
$ mk-table-checksum --replicate=mysql.checksum <マスタ名> -uroot -pxxxxxxxxxxxx -S/usr/local/db_data/mysql/mysql.sock 

DATABASE TABLE                     CHUNK HOST    ENGINE      COUNT         CHECKSUM TIME WAIT STAT  LAG
mysql    columns_priv                  0 sssdb12 MyISAM          0             NULL    0 NULL NULL NULL
mysql    db                            0 sssdb12 MyISAM         24         7bed06ed    0 NULL NULL NULL
                                        (略)
DATABASE  TABLE                 CHUNK HOST    ENGINE      COUNT         CHECKSUM TIME WAIT STAT  LAG
quest001i tbl_quest_item_hist1      0 sssdb12 InnoDB        298         61b07870    0 NULL NULL NULL
quest001i tbl_quest_user1           0 sssdb12 InnoDB     250027         333f3110    1 NULL NULL NULL
quest001i tbl_quest_user_area1      0 sssdb12 InnoDB          5         29fa5071    0 NULL NULL NULL

5.マスタとスレーブの比較
スレーブから実行します。
$ mk-table-checksum --replicate-check=1 --replicate=mysql.checksum <マスタ名> -uroot -pxxxxxxxxxxxx -S/usr/local/db_data/mysql/mysql.sock 

Differences on P=3306,h=sssdb13.smc.indexweb.co.jp
DB        TBL                   CHUNK CNT_DIFF CRC_DIFF BOUNDARIES
quest001i tbl_quest_item_hist1      0        0        1 1=1
quest001i tbl_quest_user1           0       -2        1 1=1
quest001i tbl_quest_user_area1      0        0        1 1=1