ハードディスクメンテナンス ブログ

ハードディスクの診断、物理フォーマット、静音化、Linux、サーバー、MySQLなどがメインだったのですが、その後広がり、カメラやハードウェアの投稿も増えてきました。 モバイルデバイスは、MacBookAir(13型)、iPad Air2、ポメラ DM100(キングジム)OLYMPUS STYLUS XZ-2など。 これらを使いながら、ブログを更新しています。

2014年01月






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

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

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

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

残り時間:559時間wwwww

0.4MB/swwwwwwwwww

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

このNAS、危険杉流wwwwwwwwww

NETGEAR Inc. ReadyNAS 104 【3年保証】 4ベイ Diskless RN10400-100AJS
ネットギア (2013-05-31)
売り上げランキング: 1,853
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!






パソコンの起動時に、

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

というエラーが出現。

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

-----

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

MSVCR80.dll が見つからなかったため、このアプリケーションを開始できませんでした。
アプリケーションをインストールし直すとこの問題は解決される場合があります。


OK

-----

てか、

アプリケーションをインストールし直すとこの問題は解決される場合があります

とあるが、何のアプリか不明であり、エラー画面の意味をなさない。

で、このエラー、どうもiTunesが原因のようだね。

そういえば、iTunesのUpdateが昨晩にあり、それを行った記憶がある。

Apple Software Update
Apple Software Update

解決方法は、iTunesの削除後再インストールかと思われるが、それでも解決しないことがある。

その場合は、iTunes関連のソフト、具体的には

iTunes
Apple Software Update
Apple Mobile Device Support
Bonjour
Apple Application Support

を削除し、iTunesを再インストールすればよい(iTunes以外の4つは付いてくる)。

過去には、iTunesが起動せず、再インストールできない、
または再インストールができてもiTunesが起動しない場合に
iTunes関連のソフトの全削除を行い、解決したことがある。

Appleのアプリは、Windows上では●ソだね。

iCloud不安定杉だし、iTunesのUpdateも、通知画面からUpdateを行うと、かなりの頻度で失敗する(今回のエラーは別)。

不安定→Winが●ソ→Macへ移行、というであるかは不明だが(笑)
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr Clip to Evernote






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

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

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

-----

そのまま放置すると、末期症状にwwwww

NETGEAR Inc. ReadyNAS 104 【3年保証】 4ベイ Diskless RN10400-100AJS
ネットギア (2013-05-31)
売り上げランキング: 1,853
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!






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版
Baron Schwartz Peter Zaitsev Vadim Tkachenko
オライリージャパン
売り上げランキング: 56,487
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr Clip to Evernote






新記事[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となり、不可wwwww

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を使うと高速化できるのは分かるが、コードが長くなるし、直感的でもないし、スマートじゃないね...

-----

`reg_time`にはミリ秒は格納されていないので、23:59:59.x秒が範囲外になることはない。

-----

BETWEEN '2014-01-01' AND '2014-01-01' + interval 1 day ;

とすると短く書けるように思えるが、これは 2014-01-02 00:00:00 を含むので、不適である。

INTERVALは両端を含む仕様だからだ。

実際に試してみる。

以下のようなテーブルがあり、カラム(reg_time)に以下が格納されている。

2014-01-01 23:59:59
2014-01-02 00:00:00
2014-01-02 00:00:01
2014-01-02 00:00:02

これに対し、

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

を投げると、結果は

2014-01-01 23:59:59

の1件が返されるが、

SELECT * FROM `テーブル名` WHERE `reg_time` BETWEEN '2014-01-01' AND '2014-01-01' + INTERVAL 1 day ;

を投げると、結果は

2014-01-01 23:59:59
2014-01-02 00:00:00

となり、2件返されてしまう。

+ INTERVAL 1 dayでは、

2014-01-02 00:00:00(翌日の00:00:00)

含まれてしまうのでアウト。

データに「00:00:00」が記録されているかはその記録頻度にも寄るが、開発時点で含まれていなければ「問題ナシッ!」てコトで通ってしまいかねない(笑)

で、運用開始後、「00:00:00」が記録され、一致せずに「オカシーナー♪」となる。

なら、

SELECT * FROM `テーブル名` WHERE `reg_time` BETWEEN '2014-01-01' AND '2014-01-01' + INTERVAL 1 day - INTERVAL 1 SECOND ;

と書けばどうなるのかはシラン(SILANE)。

関連:[MySQL] 日付比較や日付検索が遅いのでBETWEENで改善させる

MySQL全機能バイブル ~現場で役立つAtoZ~
鈴木 啓修
技術評論社
売り上げランキング: 199,175


実践ハイパフォーマンスMySQL 第3版
Baron Schwartz Peter Zaitsev Vadim Tkachenko
オライリージャパン
売り上げランキング: 56,487
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!

このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr Clip to Evernote

このページのトップヘ