page_adsence

2013年9月13日金曜日

ファイルを削除したにも関わらずディスク容量が増えない場合

DBメンテナンス作業時にデータファイルのコピー作業をしていたら、コピー先のサーバのディスク容量が一杯になってしまい、書き込みが出来ない状況に陥ってしまいました。
そこで、今までコピーしたファイルをディレクトリごと全て削除してディスク容量を確保しようとしたが、dfコマンドで確認するとディスク使用量が40GB程なのに対し、duコマンドで各ディレクトリの使用量の合計を計算すると1GB程度しかなかった。

原因を調べてみると、どうやらゾンビファイルとやらがある状態のため、dfコマンドでは空き容量が増えていなかったらしい。
ゾンビファイルの確認するために現在開いているファイルのプロセスを特定する必要があるので、lsofコマンドを使って調べてみる。
※ちなみにゾンビファイルとは見た目上は消えているが、プロセスが掴んでいるのでkernel上はまだ残っている状態のことだそうです。

このコマンドを使用すると、使用しているプロセスと、掴んでいるファイル名、ファイル容量がわかるのだが、確認してみると、どうやら落としたはずのMySQLプロセスが落ちていなかった。
どうやら誤って別のプロセスであるApacheプロセスを落としてしまっていた。
改めてMySQLプロセスを落とすと、ディスク容量が一気に40GB増えた。
これで一安心。

2013年8月9日金曜日

PDFからJpeg画像に変換時に発生するエラーに関して

あるpdf画像をjpeg画像に変換しようと思ったところ、検証用に使用しているサーバや本番用のサーバでエラーが出てしまった。

コマンドは以下の通り。
convert -quality 75 -density 600 -geometry 858x1215 1375856384.pdf 1375856384.jpg


エラーの内容は以下の通り。
   **** Warning: can't process font stream, loading font by the name.
   **** Error reading a content stream. The page may be incomplete.
Error: /typecheck in --run--
Operand stack:
   --dict:16/16(L)--   1.0   1.0
   --dict:16/16(L)--   1   10   HiraKakuPro-W6   8.5
   --dict:5/5(L)--
   --dict:5/5(L)--   HiraKakuPro-W6
   --dict:10/12(ro)(G)--   --nostringval--   CIDFontObject
   --dict:7/7(L)--
   --dict:7/7(L)--   12   Adobe-Japan1
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--
   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1894   1   3   %oparray_pop   1893   1   3   %oparray_pop   1877   1   3   %oparray_pop   --nostringval--   --nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1161/1684(ro)(G)--   --dict:1/20(G)--   --dict:82/200(L)--   --dict:82/200(L)--   --dict:108/127(ro)(G)--   --dict:291/300(ro)(G)--   --dict:23/30(L)--   --dict:6/8(L)--   --dict:25/40(L)--   --dict:20/25(L)--   --dict:5/5(L)--   --dict:10/15(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 9.04: Unrecoverable error, exit code 1
convert: Postscript delegate failed `/hogehoge/1375856384.pdf': そのようなファイルやディレクトリはありません @ pdf.c/ReadPDFImage/611.
convert: missing an image filename `/hogehoge/1375856384-000001.jpg' @ convert.c/ConvertImageCommand/2806.


他のpdf画像では全く問題なく変換されているので、そのpdfに問題があるかと思い、色々調べてみました。
とりあえずエラーの内容としては 「Ghostscript 9.04: Unrecoverable error」と書かれていたので、
Ghostscrip周りを調べてみたら、以下のようなサイトがあった。

http://bugs.ghostscript.com/show_bug.cgi?id=692499

Ghostscriptのバグっぽい内容の記述があるのですが、
英語で書いてあってよくわからず、とりあえず一番最後にアップグレードしろと書かれていたので、
ローカルサーバで試してみた。
現状入っていたGhostscriptのバージョンが8.15と大分古かったので、一気に最新版である9.07にアップデート。
最初はyumからアップデートしようとしたが、なかったのでrpmを探してみたが、
md5のチェックサムが一致しないと。。。 リビルドの仕方がよくわからなかったので、ソースだけ抜き出してインストールするはめに。
どうやらconfigureオプションに「--disable-compile-inits」と記述をしておかないとインストール後に設定変更できなくなるらしいです。
実際に指定したオプションは以下の通り。

./configure --disable-compile-inits --with-x --with-drivers=ALL --without-luratech --with-libiconv=gnu


で、makeしてmake installしたら入った。

gs -v

Ghostscriptのバージョンを確認し9.07に変わっていることを確認。

同じコマンドを実行。
問題なく変換出来た。
この時点で最初の8.15で変換出来るかどうか試しておけばよかったと激しく後悔。

とはいえもう遅いので、とりあえずバージョンを9.05に落としてみた。
こちらもソースから落としてきて、同様のconfigureオプションを指定しインストール。
バージョンが変わったことを確認して同じコマンドを実行。

変換出来てしまった・・・。

こうなってくると問題はImageMagickの方かもということで、ImageMagickをアップデート。
現状自分のローカルサーバに入っているImageMagickのバージョンは6.2.8。
検証、本番サーバに入っているImageMagickのバージョンは6.5.5-6。
なので、とりあえず検証サーバと同じバージョンにアップデート。
こちらもソースからインストール。configureオプションは特に指定していません。

convert -version


バージョンが変わっているかを確認。
そして変換!
エラー。
再現出来ました。
やはりImageMagickのバージョンのせいらしい。
ImageMagickを最新のバージョン(6.8.6-8)にアップデートしてみる。

変換→エラー。

どうやら最新のバージョンでも変換出来ないらしい。
バージョンを一番最初にインストールされていたバージョンに落とすしか対応方法は無さそうな・・・。

ちなみに変換出来なかった原因はpdfファイルの中に編集可能なテキストエリアがあったため、変換出来なかったっぽいです。その部分を削除し変換コマンドをかけたら問題のバージョンでも問題なく変換出来ました。

結果的に対応不要となりましたが、本当に対応が必要になった時にダウングレードして対応出来るのかは引き続き調べてみる。

2013年8月7日水曜日

GROUP_CONCATとDISTINCTの合わせ技

GROUP_CONCATとDISTINCTの合わせ技が結構便利な気がするのでメモ。 
 
以下の様なデータが登録されているテーブルがあるとする。 

mysql> SELECT * FROM TEST1;
+----+------+------+
| id | val1 | val2 |
+----+------+------+
|  1 |  100 |  115 |
|  2 |  100 |  100 |
|  3 |  120 |  100 |
|  4 |  100 |  115 |
|  5 |  100 |  115 |
+----+------+------+
 
GROUP_CONCATでまとめる。 
mysql> SELECT GROUP_CONCAT(val1) val1 FROM TEST1 GROUP BY val2;
+-------------+
| val1        |
+-------------+
| 100,120     |
| 100,100,100 |
+-------------+

GROUP_CONCATでまとめるだけだと、val1の中に重複した値が残ってしまう。
こういった値を無くしたい場合に使えるのがDISTINCTである。


SELECT GROUP_CONCAT(DISTINCT val1) val1 FROM test GROUP BY val2;
+---------+
| val1    |
+---------+
| 100,120 |
| 100     |
+---------+

重複していたデータが消えてすっきり。

2013年8月4日日曜日

自宅でダーツ

ダーツバーに毎回行くのも面倒だし、お金も勿体無い気がしたので、家でも練習できるようダーツボードを買っちゃいました。

普段やるのはソフトダーツなのですが、家でやるならハードダーツの方が静かだということで、ハードダーツボードも検討したのですが、ダーツボードのサイズも違うので、結局ソフトダーツボードを買うことに決めました。
最初は3000円位のやつを買おうかとも思ったのですが、せっかくなので奮発してPCにUSBで接続することで、ダーツゲーム画面も表示されるようなものを買いました。効果音とか、アワード画面とか色々カスタマイズ出来るのも購入に至るまでのポイントでした。

買ったのはEPOCH社のPC-DARTS2!
21500円也

毎回ダーツに行くたびに1200円位なので18回分と考えれば、そこまで高くない金額かなと。まぁDARTSLIVEカードに記録は残りませんが。

で、早速楽天でポチッと。
2日後に届きましたが、どうやらそのまま使うと結構うるさいらしいので、色々と静音対応しました。
1.シングル、ダブル、トリプル、BULL等の各セグメントを全て外して、外周に両面テープを貼ってフレームとセグメントの隙間を埋める。両面テープの白い紙は剥がさない。
2.各セグメントが押された時に通電するような仕組みのフィルムが中に入っているのですが、そのまま使用していると衝撃が強すぎてフィルムが凹んでしまうという自体が起きるらしいので、薄めのゴムシートで保護。フェルトも一緒につけていたのですが、あまりにも反応しなくなってしまったので剥がしました。
3.ダーツボードの裏側はスカスカで、それが原因でうるさいらしいので、パテ盛りしました。計4kg。ダーツボードが一気に重たくなりました・・・。

ダーツボード側に行った作業は以上。

次に設置するために買ったもの。
突っ張り棒 × 2
金属ネット × 1
突っ張り棒に金属ネットを引っ掛けるための金具 × 2
金属ネットを突っ張り棒に固定するための金具 × 2
周囲8箇所に穴を開けた木製の板 400 × 400mm 1枚
ウレタンシート 400 × 400mm 1枚
スポンジシート 400 × 400mm 1枚
キズ・音防止用粘着フェルト × 4枚

1.設置場所に突っ張り棒を2本立て、金属ネットを引っ掛け金具にかけて固定金具で固定。
2.その金属ネットに木製の板の穴に結束バンドを通して固定。
3.ダーツボードを引っ掛けるための木ねじの位置を探り、その位置に木ねじを3本ねじ込む。
4.ダーツボードと木製ボードが直接接触しているとうるさいので、ウレタンシートとスポンジシートを重ねて、ダーツボードと木製ボードの間に挟む。

木製ボードにダーツボードを引っ掛けるのが一番大変でした・・・。
IN-BULLの中心が173cmになるように木製ボードにダーツボードを固定する位置を探すのに四苦八苦。
また、固定用の金具も色々と試してみたのですが、結局ダーツボード付属の木ねじで固定しました。
多少長さが長いのは承知でつけたので、若干貫通してしまいましたが、まぁまぁ問題なく引っ掛けることが出来ました。

とりあえずこの状態で一回試しに遊んでみた。
なかなかいい感じ。
ただ、失投した時に壁紙に凹みが出来てしまったので、それを防ぐためにジョイントカラーマットを購入して壁に敷きました。

とりあえずこれで完成!
これからもちょいちょいいじっていきたいと思います。

2013年8月1日木曜日

DARTSLIVEカード買いました。

ダーツライブという機種専用のカードを買いました。
これで毎回の記録が保存されるようになりました。
現状のレーティングも出てくるので、頑張ってAフライトになれるよう精進していきたいと思います。

2013年7月30日火曜日

ダーツ始めました。

会社の人に誘われてダーツ始めました。
渋谷のBAT-DARTSというお店で、誕生日月の人は安くなるという話だったので、せっかくだからマイダーツを買ってみました。

お店で試しに投げてみて一番投げやすかったバレルはBASARAの水蓮というものを買いました。これはバレルだけではなくシャフトやフライト、チップが全部セットになったものだったので、これだけ買ってダーツバーへ。

初めてダーツバーなる所に行ってみましたが、店内はバーカウンターと2台のダーツ台が設置されている小じんまりとした感じです。
19時半頃に入ったので、まだ他のお客さんはいませんでした。

01ゲームやクリケットを何回かやったのですが、難しいですね。
全然思った通りに飛ばない。
指先から離れるときに親指と人差し指に均等に力が伝わっていないのか、右に左にずれるずれる・・・。

これからもっと練習していきたいと思います。

2013年6月20日木曜日

MySQLのViewは高速化するわけではない

MySQLのViewはショートカットみたいなもので、Viewに対して処理をするとViewで書かれているSQLを毎回実行している。
SQL文自体はシンプルになるが、高速化されているわけではない。
 もし本当にViewを使って高速化を図るのであればoracleのマテリアライズドビューを使う必要がある。マテリアライズドビューはViewを作るために利用されているSQLを定期的に実行し、 その結果のスナップショットをとっておくようになっているため、Viewに対してSQLが流れても、そのスナップショットを元に取得するようになっているため、高速化が期待できる。
マテリアライズドビューを使用するにあたって一番の問題点はマテリアライズドビューのスナップショットを更新するタイミングにある。
スナップショットを更新するには当然負荷が掛かるので、どのタイミングで更新し、スナップショットを取っておくかが要検討事項となる。

2013年5月15日水曜日

MySQLの勉強法と構築法

最近MySQLに詳しい人と一緒に仕事をすることになり、結構色々と勉強になることを教えてもらったのでメモを残しておく。

プログラム全般に関して
プログラムのデザインパターンやソート関連のアルゴリズムは目を通しておく程度に勉強しておいた方がよい。
自分の中で概念のインデックスを作ることで、それを手がかりに実装方法を検索しプログラミングすることができる。

データベースソフトウェアに関して
データペースソフトに関してはOracleが最も優れているので、Oracleで実装されている機能を覚えておくとよい。(MySQLで実装されていなくとも、それに似たことをすることは出来る可能性がある。)

DB設計に関して
画面仕様書が出来る前にDB設計をすることはWeb系の案件ではほぼ皆無なので、画面からDB設計を行っていけるようにする。
設計の大まかな手順
1.画面上から保存しないといけない要素の洗い出し
2.正規化を行い、各テーブルに振り分ける

プログラミングに関して
プログラムを書く際には、DB側で出来る処理は全てDBに任せる。
DBでどうしても出来ないものに関してはWeb側で処理をする。
理由はユーザーの流入経路がWebからDBの順番であるから。
Web側にはユーザー数とイコールの関係で負荷が掛かるが、DBに関してはDBアクセスが必要なページ以外では負荷がかからないので、Web側の負担を軽くするために、なるべくDB側に寄せる方が懸命である。

データベースエンジンの選び方に関して
ログ系や認証系のものを保存するのであればMyISAMやKVSが向いている。
但し、1つのDBサーバにエンジンが異なるものを使用するのは現実的ではないため、大概のシステムでInnoDBが採用されている。
もし本当にDBを分ける必要があれば、エンジンごとに別のDBサーバを使用するのがよい。

MySQLのカラム数に関して
MySQLのカラム数が100を超えると格段にパフォーマンスが下がるので、その場合は正規化してやる必要がある。
そうすることで、インデックスの数も減るし、オプティマイザが迷うことが少なくなるので、高速化される。

とりあえず今日話した内容はざっくりこんな感じ。