2017.01.20
カテゴリ： ソフト開発日誌
OS キャッシュを通さず SONY MicroSD card SR-16UY の速度を測った
Random write のプロットはほぼ OS が管理している cache に格納する動作になった。 (rw1), (rw3) の方は書き込み長 1Mibyte まて TAT は 1ms または 2ms となった。タイムスライス間隔なのかもしれない。このことからすると、先のランダム読み出しで 2 筋現れる傾向は OS の動作も原因の可能性有りと考える必要がある。 (rw2) の方の筋は cache に書き込んですぐ userland に戻った場合のプロットと言える。デバイスにアクセスしない場合は 2us で処理を終えている。 500,000 IOPS だ。SR-16UY のアクセス時間に対して十分に短いと言える。 (rw4) 稀にアクセス時間が 10 秒を超えるケースが散見される。組み込み Linux の root file system に使った場合、アプリが稀に応答しなくなる現象が有る可能性を念頭に置くか、書き込みは別スレッドにするなどの工夫を必要とする。
Random read のプロットは (rr1), (rr2) の筋がはっきりと出ている。 (rr1) の方は MicroSD から読み出している動作だと考えられる。OS のキャッシュを使わない O_BLOCK を付けた 条件で測定したアクセス時間よりも長くなっている。まるで書き込みをしているかの様な access 時間だ。例えば 1Mbyte で 200ms なので 5Mbytes/sec。先行して発行された write access に伴う wear leveling を読み出し要求があった block を積極的に使って行っているのだろうか。ランダムに read したブロックがすり減り (wear) 度合を平均化するのに丁度良い block とは限らないと思う。MicroSD 内で動いているアルゴリズムはどうなっているのだろうか。 (rr2) の筋は OS の cache read だろう。転送長 1kbyte 付近でアクセス時間は 1us を切っている。
(rr3) ランダムアクセステストの生データ 調べてみると、アクセス時間が 200 秒を超える場合が 5 回あった。下の表をクリックするとテキストでアクセスできる表を表示できる。
Linux は Userland process が 120 秒以上割り込み不可状態を維持すると(see. /proc/sys/kernel/hung_task_timeout_secs)、hung_task_panic が 1 の場合 panic してしまう。panic が起きなくても、プロセスが 100 秒以上止まるのだから、ハングアップと思われてしまうような処理遅延、取りこぼしが起きる。
高負荷でしか起きない現象か？自分の経験からすれば、このような傾向を示す Flash memory storage は低負荷でも何かの拍子で access time が 100 秒以上になってしまう事が有った。
「何かの拍子」と言うのが厄介だ。アクセス順に付けた index をキーに先の生データを精査しても、アクセス時間を長くしてしまう規則性を見いだせない。
MicroSD で access time が異常に長くなる傾向が有る品種は結構ある。SR-16UY も root file system を格納する用途は想定していないと思われる。テストしてみてふるい分けるしかない。
そうだ、MicroSD に書き込んですり減らすのが目的ではなく、使うことが目的なんだよな...
Random write のプロットはほぼ OS が管理している cache に格納する動作になった。 (rw1), (rw3) の方は書き込み長 1Mibyte まて TAT は 1ms または 2ms となった。タイムスライス間隔なのかもしれない。このことからすると、先のランダム読み出しで 2 筋現れる傾向は OS の動作も原因の可能性有りと考える必要がある。 (rw2) の方の筋は cache に書き込んですぐ userland に戻った場合のプロットと言える。デバイスにアクセスしない場合は 2us で処理を終えている。 500,000 IOPS だ。SR-16UY のアクセス時間に対して十分に短いと言える。 (rw4) 稀にアクセス時間が 10 秒を超えるケースが散見される。組み込み Linux の root file system に使った場合、アプリが稀に応答しなくなる現象が有る可能性を念頭に置くか、書き込みは別スレッドにするなどの工夫を必要とする。
Random read のプロットは (rr1), (rr2) の筋がはっきりと出ている。 (rr1) の方は MicroSD から読み出している動作だと考えられる。OS のキャッシュを使わない O_BLOCK を付けた 条件で測定したアクセス時間よりも長くなっている。まるで書き込みをしているかの様な access 時間だ。例えば 1Mbyte で 200ms なので 5Mbytes/sec。先行して発行された write access に伴う wear leveling を読み出し要求があった block を積極的に使って行っているのだろうか。ランダムに read したブロックがすり減り (wear) 度合を平均化するのに丁度良い block とは限らないと思う。MicroSD 内で動いているアルゴリズムはどうなっているのだろうか。 (rr2) の筋は OS の cache read だろう。転送長 1kbyte 付近でアクセス時間は 1us を切っている。
(rr3) ランダムアクセステストの生データ 調べてみると、アクセス時間が 200 秒を超える場合が 5 回あった。下の表をクリックするとテキストでアクセスできる表を表示できる。
Linux は Userland process が 120 秒以上割り込み不可状態を維持すると(see. /proc/sys/kernel/hung_task_timeout_secs)、hung_task_panic が 1 の場合 panic してしまう。panic が起きなくても、プロセスが 100 秒以上止まるのだから、ハングアップと思われてしまうような処理遅延、取りこぼしが起きる。
高負荷でしか起きない現象か？自分の経験からすれば、このような傾向を示す Flash memory storage は低負荷でも何かの拍子で access time が 100 秒以上になってしまう事が有った。
「何かの拍子」と言うのが厄介だ。アクセス順に付けた index をキーに先の生データを精査しても、アクセス時間を長くしてしまう規則性を見いだせない。
MicroSD で access time が異常に長くなる傾向が有る品種は結構ある。SR-16UY も root file system を格納する用途は想定していないと思われる。テストしてみてふるい分けるしかない。
そうだ、MicroSD に書き込んですり減らすのが目的ではなく、使うことが目的なんだよな...
お気に入りの記事を「いいね！」で応援しよう
最終更新日
2017.01.20 16:19:31 コメントを書く
[ソフト開発日誌] カテゴリの最新記事
-
Final Data Photo Recovery 9.0 - exFAT … 2024.06.06
-
商用電源監視サーバー更新 - 閏年 2/29 以… 2024.05.31
-
Futaba M202MD10B アプリ と コマンドシー… 2023.09.05
【毎日開催】
15記事にいいね！で1ポイント
カレンダー
サイド自由欄
コメント新着
© Rakuten Group, Inc.
