2014年01月31日

たかだか500GBのコピーに「あと559時間」！遅杉流ｗｗｗｗｗ(ReadyNAS 104)

遅杉のReadyNAS 104(RN10400-100AJS)の件。

コピー開始後、しばらくは20MB/sくらい出ているのだが、ドンドン速度が低下し、そのまま放置すると、

ReadyNAS 104,RN10400-100AJS,コピー,遅い

残り時間：559時間ｗｗｗｗｗ

0.4MB/sｗｗｗｗｗｗｗｗｗｗ

で、経時とともに速度は低下していくので、時間が経つにつれ残り時間が増加する罠ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

このNAS、危険杉流ｗｗｗｗｗｗｗｗｗｗ

NETGEAR Inc. ReadyNAS 104 【3年保証】 4ベイ Diskless RN10400-100AJS

posted with amazlet at 14.03.03

ネットギア (2013-05-31)
売り上げランキング: 1,853

Amazon.co.jpで詳細を見る

タグ：: ReadyNAS; 104; RN10400-100AJS; コピー; 遅い

[PR] au PAY / au WALLET カード情報

2014年01月30日

APSDaemon.exe - コンポーネントが見つかりません

パソコンの起動時に、

APSDaemon.exe - コンポーネントが見つかりません

というエラーが出現。

タグ：: APSDaemon.exe; MSVCR80.dll; iTunes; エラー; コンポーネント

[PR] au PAY / au WALLET カード情報

2014年01月29日

ReadyNAS 104(RN10400-100AJS)が遅杉の件

あるファイルサーバー(Atom機)からNETGEARのNASであるReadyNAS 104(RN10400-100AJS)にファイル群(500GB程度)をコピーすると徐々に速度が落ち0.3MB/sとかなり終了まで250時間とかフザけたことになると書いたが、

そのAtom機から、別のWindowsマシンに接続したハードディスク(USB2.0接続)に同じファイル群をコピーすると、約1日で終了する罠。

これはつまり、ReadyNAS 104(RN10400-100AJS)が●ソということになるのか？

タグ：: ReadyNAS; 104; RN10400-100AJS; 遅い

[PR] au PAY / au WALLET カード情報

2014年01月28日

(MySQL) key_buffer_sizeの変更 (Debian)

key_buffer_sizeとは、indexの常駐量。

これがデフォルトでは8MB？と小さすぎるので、これを調整する。

# ハードウェアが贅沢になったともいえる。

① コマンドでrootでログイン

② MySQLにログイン

mysql -u root -p

MySQLにログインする際のパスワードは①のモノで。

③ key_buffer_sizeの値を調べる

show variables like 'key_buffer_size' ;

+-----------------+----------+
| Variable_name | Value |
+-----------------+----------+
| key_buffer_size | 16777216 |
+-----------------+----------+
1 row in set (0.00 sec)

この時の/etc/mysql/my.cnf中の記述は

key_buffer = 16M

となっている。

MySQLのバージョンによって？はkey_buffer_sizeとなっていることもある。

桁区切りは

16,777,216(bytes)

なので、これは

16(M)777(K)216(bytes)

であり、16MB。

ということは、my.cnf中の記述で「16M」という表現でOK？

④ my.cnfを書き換えてUploadする。

key_buffer = 512M

⑤ MySQLからログアウト。

mysql > exit

⑥ MySQLを再起動する。

/etc/init.d/mysql restart

再度以下で値を確認する。

show variables like 'key_buffer_size' ;

+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| key_buffer_size | 536870912 |
+-----------------+-----------+
1 row in set (0.00 sec)

536,870,912(bytes)

536(M)870(K)912(bytes)

なお、私の問題になっている環境では、512Mにしても1M(1,048,576bytes)にしても変化はなかった。

他の設定や、SQL文の見直しなどが必要になる。

とりあえずは256M(268,435,456bytes)にしておいた。

あまり大きくし過ぎるとメモリを圧迫するので、Debian端末が搭載する総メモリ容量の確認方法により総メモリを確認の上、適量を割り振ろう。

実践ハイパフォーマンスMySQL 第3版

posted with amazlet at 14.03.03

Baron Schwartz Peter Zaitsev Vadim Tkachenko
オライリージャパン
売り上げランキング: 56,487

Amazon.co.jpで詳細を見る

タグ：: key_buffer_size; 変更; 調整; MySQL; Debian

[PR] au PAY / au WALLET カード情報

2014年01月27日

日付比較や日付検索が遅い場合の改善方法(BETWEEN,MySQL)

新記事：[MySQL] 日付比較や日付検索が遅いのでBETWEENで改善させる

datetime型の列(reg_time)があるテーブルに対し、年月日指定をかけてデータを取り出す。

注：datetime型の例：2014-01-01 12:34:56

SELECT * FROM `テーブル名` WHERE `reg_time` LIKE '2014-01-01%'

これは非常に遅い。

reg_timeにindexを設定しても、indexが使用されないので無意味。

初心者が多用するLIKEなんか使うからだよ！ということで、dateを使うが、

注：dateはdatetime型(2014-01-01 12:34:56)から年月日(2014-01-01)を取り出す関数。

SELECT * FROM `テーブル名` WHERE date(`reg_time`) = '2014-01-01'

これも同様に遅い(indexも使用されない)。

この解決方法は、BETWEENを使用することである。

SELECT * FROM `テーブル名` WHERE `reg_time` BETWEEN '2014-01-01 00:00:00' AND '2014-01-01 23:59:59'

これにより、高速化が可能。

EXPLAINで動作を見ると、typeがallからrangeになっていることが分かる。

typeは、テーブルに対してどのような方法でアクセスするのかを示すもの。

allはフルテーブルスキャンで、インデックスが全く使用されていないことを表す、最悪なモノだ。

一方rangeは、インデックスを用いた範囲検索である。

2014年1月1日の始端(00:00:00)と終端(23:59:59)を設定し、その間(BETWEEN)とすれば、同じものがSELECTでき、強引にBETWEEN化できるのは分かる。

まぁ、これはそれでよいとして、年月指定(日がない)の場合はどうか。

月毎の集計とかね。

当然、

SELECT * FROM `テーブル名` WHERE `reg_time` LIKE '2014-01-%'

は遅く、同様に

SELECT * FROM `テーブル名` WHERE LEFT(`reg_time`,'7') = '2014-01'

や

SELECT * FROM `テーブル名` WHERE LEFT(`reg_time`,'8') = '2014-01-'

注：LEFT(`reg_time`,'7')は、reg_timeの左から7文字を取り出す、つまり年-月を取得する関数。

も遅い。

となると、高速化が考えられるのはBETWEENとなるが、時刻の場合は終端が23:59:59で決まるが、月日の場合の終端日はどうするか？

終端日は、月によって異なるだろう？

まぁ、ダメだと思って

SELECT * FROM `テーブル名` WHERE `reg_time` BETWEEN '2014-01-01 00:00:00' AND '2014-01-32 23:59:59'

とすると...

エラーにはならないが、返された結果が0となり、不可ｗｗｗｗｗ

32日は存在しない日だからだろう。

となると、その月の最終日(月末日,晦日)を求めなければならない。

PHPであれば、

cal_days_in_month(CAL_GREGORIAN,$month,$year)

という関数がある(年と月の順序に注意)。

これは月末を求める関数ではなく、その年月の日数($hikazu)を求めるものだ。

日数が分かるということは、最終日($last_day)は

$hikazu = cal_days_in_month(CAL_GREGORIAN,$month,$year) ;

$last_day = $year."-".sprintf("%02d",$month)."-".sprintf("%02d",$hikazu) ;

として求められるので、

$from = $year."-".sprintf("%02d",$month)."-01 00:00:00" ;

$to = $last_day." 23:59:59" ;

SELECT * FROM `テーブル名` WHERE `reg_time` BETWEEN '$from' AND '$to'

とすればよい。

また、MySQLの日付/時刻関数にlast_dayというものがある。

これは、与えた年月日の月末(年月日)を返す。

last_day('2014-01-01') → 2014-01-31

これを使うと、

$from = $year."-".sprintf("%02d",$month)."-01" ;

SELECT * FROM `テーブル名` WHERE `reg_time` BETWEEN CONCAT('$from',' 00:00:00') AND CONCAT(last_day('$from'),' 23:59:59')

とすることができる。

BETWEENを使うと高速化できるのは分かるが、コードが長くなるし、直感的でもないし、スマートじゃないね...

タグ：: MySQL; 日付; 比較; 検索; datetime; 遅い; BETWEEN

[PR] au PAY / au WALLET カード情報