作成者別アーカイブ: 鮎

攻撃が激しいのでiptablesで中国・韓国からのアクセスを遮断する

投稿日: 2012年10月16日 作成者: 鮎

　最近、島問題の影響のようでさくらVPSやお名前.com VPS(KVM)のホストにも大陸や半島方面からのDoS的なアクセスがままあってそのたびにホスト制限していたのですが、面倒くさいので、アドレス割り当て情報から大陸と半島からのアクセスを制限するためのiptables設定をしました。

　-Aじゃなくて-Iなのは、許可ルール以前にこのIPを拒否したいため。
　シェル実行してから /etc/init.d/iptables save で保存できる。

　ドロップしたパケットを記録したい場合は、

-N LOGDROP
-A LOGDROP -j LOG –log-prefix “[iptables drop]”
-A LOGDROP -j DROP

みたいに、新しい挙動LOGDROPを定義して、LOGDROP挙同時にはLOGってDROPする動きにする。
　で、従来の-j DROPの代わりに-j LOGDROPにしてやると、messagesログファイルにドロップした情報が記録されるようになる。
　LOGDROPを定義せずにLOGって、DROPしてを繰り返し書いても良いけど、数が多いときはこの方が楽。

(1035)

このエントリーをはてなブックマークに追加
はてなブックマーク - 攻撃が激しいのでiptablesで中国・韓国からのアクセスを遮断する

カテゴリー: サーバ設定 | タグ: , | コメントをどうぞ

MySQLチューニング：ソートやグルーピングするテーブルが大きいときはサブクエリを挟んだ方が速かった

投稿日: 2012年10月15日 作成者: 鮎

　MySQLの便利機能でGROUP_CONCATってのがある。

SELECT primary_id, GROUP_CONCAT(item_id) AS item_id_list FROM stock GROUP BY primary_id ORDER BY primary_id ASC LIMIT 50

みたいにすると、stockテーブルのprimary_idでグループ化して、そのグループ内のitem_idをカンマ区切りで返してくれる。
　このとき、item_id_listはBLOBになったりする。
　こんな感じでもっと複雑なテーブルについてきたとき、ORDERやLIMITの関係でtmpテーブルでの作業が発生するんだけど、BLOBがMEMORYエンジンに乗らないのでボトルネックになっていた。
　さくらVPSやお名前.com VPS(KVM)では、物理マシンに比べてディスクI/Oが弱いのでTmp to Diskになると著しく遅くなるので改善したい。
　ORDERやLIMITがINDEXで直ちに確定できない場合に、巨大なデータセットがtmpになるので、とりあえずこれをサブクエリにして

SELECT s.*, GROUP_CONCAT(item_id) AS item_id_list FROM (SELECT primary_id FROM stock GROUP BY primary_id ORDER BY primary_id ASC LIMIT 50) p LEFT JOIN stock s ON s.primary_id = p.primary_id GROUP BY s.primary_id ORDER BY s.primary_id ASC

みたいにした方が高速になった。
　この場合は、外のクエリは結局tmpの処理があるんだけど、LIMIT処理がサブクエリ中でかかっているから、JOINの段階でデータサイズが小さくなってCopy to Tmp Tableの時間が短縮できる。
　中間処理テーブルが大きくてLIMITが小さい場合ほど効果的。
　まぁ、根本を直した方が良いんだけど、とりあえず、簡単な修正で処理時間を短縮できるメモ。

(1257)

このエントリーをはてなブックマークに追加
はてなブックマーク - MySQLチューニング：ソートやグルーピングするテーブルが大きいときはサブクエリを挟んだ方が速かった

カテゴリー: MySQL | コメントをどうぞ

MySQLで過去ｘ日間と言う条件を書く

投稿日: 2012年9月26日 作成者: 鮎

　MySQLで指定日数前の日付を取得する場合、

DATE(DATE_ADD(NOW(), INTERVAL -日数 DAY))

で取得出来る。

createdateに日付を入れていて、最近7日以内に作られたレコードを求める場合、

SELECT * FROM my_table WHERE createdate >= DATE(DATE_ADD(NOW(), INTERVAL -7 DAY))

みたいになる。　ちなみに -0 DAYなら今日になる。

　関連して、日付の曜日を取得する場合、

WEEKDAY(日付)

で取得する。　0が月曜で始まる。

　今週の月曜日の日付は、

DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW()) DAY))

で取得出来る。

　今週の月曜日からの記録を切り出す場合、

createdate >= DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW()) DAY))

で取得。

　先週の月曜から金曜までの記録を切り出す場合、

createdate >= DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW())-7 DAY)) AND createdate < DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW())-3 DAY))

※BETWEENは以上以下。　時刻なしのDATEは0時0分0秒扱いだから1秒減算する必要がある。

(951)

このエントリーをはてなブックマークに追加
はてなブックマーク - MySQLで過去ｘ日間と言う条件を書く

カテゴリー: MySQL | コメントをどうぞ

muninを使って、お名前.com VPSからRTXの監視をする

投稿日: 2012年9月22日 作成者: 鮎

　お名前.com VPS(KVM)に入っているMuninを使って自宅のRTX1000の監視をしてみる。

１，RTX側のSNMP設定を行う
　基本

snmp host VPSのIPアドレス
snmp community read-only public
snmp yrifppdiplayatmib2 on

　更に、NATの外から来るのでスタティックを追加

nat descriptor masquerade static NATデスクリプタ番号 テーブル番号 RTXの内側アドレス udp snmp

　snmpポートのフィルタリングを追加

ip filter フィルタ番号 pass VPSのIPアドレス RTXの内側アドレス udp * snmp
ip filter フィルタ番号 restrict * RTXの内側アドレス udp * snmp

※VPSからのSNMP要求は通して、それ以外から来た物を捨てる。

２，VPS側でmunin設定を行う
　まずはmunin-nodeを設定

ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_1’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_3’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_5’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_6’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_35’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_91’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_92’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_93’

※hoge.piyo.tldはRTXのグローバルIPorホスト名
　ifはインターフェースの通信量表示、1～3番はLAN1～3でLAN2を使っていないので1と3、4番はBRIで未使用、5番からがPPで今回はPP01と02を監視、35番はRAS用のPP Anonymous、91番からがTUNNELで今回は01～03の対地を監視。
　後は、CPUとMEMを取得するプラグインをこちらのサイトから拝借して入れる　※念のためコピーを置いておく CPU MEM

cat > /etc/munin/plugins/snmp_hoge.piyo.tld_cpu
chmod 777 /etc/munin/plugins/snmp_hoge.piyo.tld_cpu
cat > /etc/munin/plugins/snmp_hoge.piyo.tld_mem
chmod 777 /etc/munin/plugins/snmp_hoge.piyo.tld_mem

　そして、SNMP設定を設定ファイルに記述

vim /etc/munin/plugin-conf.d/munin-node

[snmp_hoge.piyo.tld*]
env.version 1
env.community public
env.host hoge.piyo.tld

　出来たらmunin-nodeを再起動

/etc/init.d/munin-node restart

　このままではmunin-nodeが値を取ってきているけど表画面には出てこないので、表側の設定も追加

vim /etc/munin/munin.conf

[hoge.piyo.tld]
address 127.0.0.1
use_node_name no

※addressはmunin-nodeのアドレスなので、ローカル動作なら127.0.0.1。

　直ちに更新してみる場合は

sudo -u munin /usr/bin/munin-cron

　これで、muninのトップにhoge.piyo.tldのページが追加されていて、各インターフェースの通信量とCPU・メモリ状況が出るようになる。

(483)

このエントリーをはてなブックマークに追加
はてなブックマーク - muninを使って、お名前.com VPSからRTXの監視をする

カテゴリー: サーバ設定 | コメントをどうぞ

Proliant ML110 G7はイイネ

投稿日: 2012年9月18日 作成者: 鮎

　以前、さくらVPSをWindows化するときにKVMを動かす環境としてProliant ML110 G7を購入していたわけだけど、ECCメモリが使えたり、フロントアクセスできるHDDケージがあったりするのが気に入って、色々拡張して使ってきた↓
・CPUをXeon E3-1280に交換
・メモリを4×2+2追加
・ケージにSAS HDD4台設置＆RAIDカードを追加(こいつのHDDケージは内部コネクタがSFF-8087なので、ちゃんとしたRAIDアダプタにつなぎ替えしてSASも繋がる)
・ビデオカード追加
・電源換装
で、普通にワークステーションっぽく使っている（全部で10万円かかってない）
　ECCメモリやそれなりのエアフローのおかげか安定性が良く、下手なブランドPCなんかより遙かに安定していて良い感じだった。

　そんなわけで、今回、調子が悪くなってきたテレビ録画サーバのリプレース用にこの機種をもう1台購入した。　まぁ、安かったのが一番のポイントだったわけだが（今回はNTT-Xで13980円にクーポン4000円引きで9980円だった）　

　今回届いた商品、アウトレットって言う事だったが、HPでちゃんとメンテ作業したのか怪しいところがある。
　蓋を開けて確認すると、エアシュラウドに埃が微妙についていてクリーニングが不十分な感じがするのと、BIOS設定は初期状態に戻っていたもののiLO3のマシン名設定とイベントログが残っていた・・・　まぁ、安かったし、クレーム出すのも面倒なのでそのまま使用することにした。

　今回のマシンはTV録画専用なので、メモリはデフォルトのまま、データ用にHDDを追加、光学ドライブをBD-Rに交換、先のマシンからRADEON HD6450を移設(あっちにはちょっと良いのを追加)、PT3とUSB3.0カードを入れた。
　OSはWindows7 32bitを入れたが、ドライバはデフォルトで(iLO管理ドライバ以外)全部入っていて、追加したビデオ・PT3・USBカードのドライバを入れるだけで普通に動いた。

　グラフィックボードを入れる場合、拡張スロットエリアの温度が上がってフロントの8cmファン(iLO3表示のFAN8)が結構五月蠅くなるので、EnermaxのMAX2200rpm PWM制御ファンに交換した。
Proliant ML110G7のファンのピンアサインは緑がファン停止検出、黄色は12V、青がPWM線で黒はGND。　ファン停止検出はGNDに落とせば異常検知されない。
PWMタイプの通常ファンはGND/12V/Sense/PWMで、通常は黒／赤／黄／青なので、黄色同士を繋がず、ファンの赤を本体の黄色に繋ぐ点だけ注意。　回転数検知はない(iLOで出る回転％は、PWMのデューティ)
　クロシコのRadeon HD6450 1GBを一番下のスロットに入れているが、3dmarkを走らせても拡張スロットエリアの温度は50度程度で収まるので、iLO表示の61度にはいくらか余裕あり。
　CPUファンとバックファンはデフォルトのままでもそれほど五月蠅くならないのでそのまま使用。
　寝室放置で特に問題ない音量で収まっている。

　NTTX版は電源が70%効率の物で、動かしっぱなしの録画サーバとしては多少節電したいと言うことで、クロシコの530W 80Plus goldな電源に交換。　吸気が上下逆転で窒息しそうだが殆ど発熱がないので問題なし。

　しかし、使えば使うほど良くできたマシンだ。
NICなんかほぼワイアスピード出るし、今時だけどRS-232Cが付いているし(レガシーなUPS繋げる)、フロントUSBが4ポートあるんで、必要なときだけキーボードやマウスを繋ぐって使い方にも良い(2ポートの機種だと1ポート足りない＝作業用のUSBメモリ、キーボード、マウスを入れたい。　最も、私はこの用途にはトラックポイントキーボードを使うんで2ポートでも大丈夫なんだけど)
iLO3が入っているからもしも上物が応答停止しても、移動中のスマホや会社のPCから入って強制再起動だって出来る。
BIOS設定でCPU制御をOS制御にしておくとEISTが効く。
　性能はお名前VPSに遙かに劣る(CPUのベンチで2倍近く差が出る)ものの、録画みたいな用途だとリアルマシンが必要になるから、こんな安売りマシンは良い感じ。

　そんなわけで、自宅にProliant2台稼働中なんて状況になったわけだけど、かなり低コストに安定環境を手に入れられて良い感じだ。

(860)

このエントリーをはてなブックマークに追加
はてなブックマーク - Proliant ML110 G7はイイネ

カテゴリー: 未分類 | コメントをどうぞ

Windows Server 2012重複除去の管理を行う – 重複除去構成の解除、空き領域の開放 – WindowsServer2012

投稿日: 2012年9月17日 作成者: 鮎

　Windows Server 2012の重複除去機能を試用していて気がついたのだけど、重複除去対象ファイルを他のボリュームへ移動したり、削除したりしてもディスク容量が空かない。
　なんだコレ、と試しに管理画面から重複除去の構成を無効化してみたけど変わらなかった。

　重複除去処理されたファイルは、中のデータ実体が専用管理されていて、デフォルトでは管理画面に無いスケジュールで週１で不要データ管理がされているようだ。
　なので、大量のファイルを削除して直ちに空き領域を確保したい場合は、その処理を手動で実行する必要がある。
　手順としては、PS(Power Shell)を管理者モードで起動して

Start-DedupJob ボリューム -Type GarbageCollection

※ボリュームは D: とか E: とか
を実行する。

　実行中の状態を調べる場合は

Get-DedupJob

を実行する。

　重複除去したディスクの重複除去を解除する場合は、

Start-DedupJob ボリューム -Type Unoptimization

を実行する。
※解除するための容量が不足する場合には処理に失敗する。

　直ちに、スループット重複除去を実行する場合は、

Start-DedupJob ボリューム -Type Optimization

を実行する。

　重複除去構成したファイルサーバで不要ファイル削除なんかの作業をした後には手動でガーベジコレクションを実行するべきと・・・
　ファイル削除しても空き領域が増えなくて焦ったのでメモっておこう。

(3193)

このエントリーをはてなブックマークに追加
はてなブックマーク - Windows Server 2012重複除去の管理を行う – 重複除去構成の解除、空き領域の開放 – WindowsServer2012

カテゴリー: Windows VPS, サーバ設定 | コメントをどうぞ

ApacheでPHPを使用して処理した大きなページを圧縮(mod_deflate使用)するとメモリリークする事がある（PHPの消費メモリが減らない）

投稿日: 2012年9月16日 作成者: 鮎

　先日の本番サーバでの出来事。
　データ関連のエクスポートを行うPHPのプログラムがあって、とあるクライアントが非常に大きいデータ（数十MB）をダウンロードし始めた。
　この時監視していたところ、本番サーバのhttpdプロセスがメモリ(RES)を500MB程度使われていた。
　まぁ、データ量がデータ量だからそんな物かと思ったのだけど、該当プロセスのCPUが0%になってもメモリがそのまま解放されない。
とりあえず、こんなプロセスがたまったらいかに本番サーバといえどもメモリが吹き飛んでサービス停止に陥る（本来はリソース計画で最大状態でも足りるように制限設定するべきなんだけど、諸事情から出来ない・・・）ので、とりあえずApacheのMaxRequestsPerChildを下げてメモリが枯渇する前に再起動するようにした；

　本番データを開発環境に入れて同じリクエストを送ってみるがメモリはちゃんと解放される。
　PHPの問題かと思ったのだけど、いまいちわからず。
　仕方ないので、本番の直近バックアップイメージを仮想環境に立ち上げて、デバッグツールを入れて走らせると再現した。
　そのでかいデータ、DEFLATEされていたのだ。　コンテンツタイプがtextだったので、OutputFilterで圧縮処理をがりがりやってたのだが、データがある程度でかいと、この時に握ったメモリが解放されない（メモリリークしてる）
　開発環境はLANの帯域があるからDEFLATEしていなかった。
　とりあえず、該当処理のアドレスをDEFLATEの除外条件にした。　けど、大きい物ほど圧縮したいなぁと思うわけだけど・・・
　PHPのメモリを制限していても、DBに繋いで読んで出してを繰り返す場合にはPHP自身は変数（メモリ）を再利用しているからそこではメモリ消費が増えず、外のmod_deflateの中だけ増え続けちゃうから、大きいデータは別処理でちゃんと圧縮してからAttachしてダウンロードするように修正かな。

　まぁ、httpdがメモリを解放してくれない場合にはmod_deflateをチェックと、メモ。

(585)

このエントリーをはてなブックマークに追加
はてなブックマーク - ApacheでPHPを使用して処理した大きなページを圧縮(mod_deflate使用)するとメモリリークする事がある（PHPの消費メモリが減らない）

カテゴリー: LAMP[Linux, Apache, MySQL, PHP], PHP, サーバ設定 | コメントをどうぞ