エントリー

2012年11月の記事は以下のとおりです。

EPIAで使うPC電源を掃除

  • 2012/11/18 20:55
  • カテゴリー:EPIAPC

電源がないと始まらないので、一年程前に交換して実験用(or緊急交換用)に保管していたPC電源を使うことにした

電源1

Pentium4 Dualで5年位使用した電源で、電源投入してみると、なんとまあうるさいこと
かなりの騒音なので掃除してみた

34

5

蓋を開けてファンを取り出しこびり付いたホコリを取って、ローター部に5-56を0.2秒位のほんの少し噴射で随分と静かになる
ファンの汚れも酷かったがケースの内側や部品の汚れが目立った

掃除前掃除後の映像(撮影はiPodでx264,aacのmpeg4に変換)

しかしこの電源やたらと効率が悪いようでマザー接続なしでも4Wも消費している
さらにEPIA ME6000を接続すると大よそ20W位のはずなのに39Wも消費・・・効率約50%とは酷すぎ

6

そこでもう1台交換前Pentium4(Prescott)~Core3で8年位利用した電源を取り出した

電源28

これが長年使った割りにファンが動いているのか?って位の静かさで驚いた
80%との表示もあり(80plus認証はしてないようだ)
一応は掃除することにして開けてみると(4箇所のネジ止めの内1箇所はシールが張られて隠されて危険と記載があり安全の考慮もされていた)

910

中身が上記のと随分と違うものだと見た目で判る(良い電源を購入していたんだなぁをいまさらながら納得)
ファンとケース裏側にこびり付いたホコリを取って、これは5-56を使う必要はなさのうなので組み立てる
やけにファン部分とその周りの汚れが酷かった

これまで電源を掃除機で風穴やファンのホコリを取るとかケースの回りを拭くことはやっていたが、ケースに装着してるのもあってか中を開けて掃除することは無かった
特にケースの内側のファンの周辺が汚れていることも判明したし、開けることでファンのホコリを完全に取り除くことができるので偶にはやっても良いかなと思う

2つの電源で汚れの箇所が異なったのは、通気の違いによるのものかと思われる
悪い場合だと部品やケースの内側の汚れが多く、良いとファンが汚れるってことかな

尚、こちらの電源ではEPIA ME6000の消費電力は26Wと表示(ほぼ効率80%で優秀)

11

当然ながら後の電源を利用することにする

EPIA ME6000G

  • 2012/11/16 15:12
  • カテゴリー:EPIAPC

10年も前のITXマザーであるVIA EPIA ME6000G(CL10000もあるが)を使って、DBバックアップのためのレプリケーション用、また臨時サーバ的な感じで利用できないかと思い倉庫に置いてあったのを取り出した

001

古いマザーではあるがBIOSでUSB-HDD起動を設定できる

そこで場所的なスペースが必要なHDDではなく、linuxを稼動するなら十分な容量になった安価なmicroSDカードにシステムを入れてみようと考えた

SDカードがどのくらい使えるか興味もあるし、SDカードでシステムが利用できれば、例えばHDDをデータ用にして停止させながらなら2.5インチHDDで長期間運用もできるのではないかという思惑もある

懸念されそうな事項としては、SDカードの性能と耐久性や信頼性があり

  • 読み込みだけなら問題ないだろう、むしろHDDより早いかもしれない(安易)
  • 耐久性については、ほとんどが頻繁に変更されないシステム部分だし、変更の多いlogはテキストなので書き換え回数があっても書き換え容量が少ないので未使用領域を多く取っておけばウェアレベリング等の処理で耐えるのではないか、また例え1年しか持たないとしても1年毎に交換すれば良い
  • 信頼性の面は不明なのでこれは試行してみるしかない

安易ではあるが面白そうなので実験してみることにした

本来ならば実用性のあるマザーを使いたいところだが、あいにく空いているマザーがEPIAの2種しかないので、しばらくはこのマザーを使うことにする

まずは電源を準備せねば

iOS6.0.1のiPod touch4

11/2にiOS6.0.1に更新して10日余り使用した

AppStoreもそこそこ使えるようになりアプリのiOS6対応も含むことになるが、iOS6にした当時の酷さは大幅に改善されたようだ

あまりにも状況が変わったので何を改善したのだろう?って深く考えることもないのだが、使用していての実感ではメモリ解放(使用中以外のアプリの停止かもしれない)が早くなったのではないかなっと思うことがある

例えば、Safariでブラウジング中に別アプリを起動し使った後Safariに戻った場合に切り替え前に参照していたサイトが再読み込みされることが増えた

Safariだけでなく別のアプリ間でも同じ様に、アプリの切り替えで前の状態が消えていることが多くなった気がする

つまりアクティブになったアプリにリソースを与えるため、同時進行(iOSマルチタスク)アプリのリソース解放条件を強化(調整)したってことかなと感じた(解放するのは停止中のアプリだと思う)

非アクティブアプリのリソース解放が厳しくなると、途中で止めたアプリが初期状態になり(一時停止状態でなくなるので)アプリ切り替えを行うことが多い場合に使い勝手が悪くなるという問題が発生することになる

残念ながらiPod4のリソースでは現在のアプリは厳しいのかもしれないが、今まさにアプリ切り替えで使い勝手が悪いって感じることがあるし、解放処理中なのか偶に待たされる現象が発生している

尚、ボタン2度クリックによる同時進行アプリは残っているので真意は不明である

MySQLを少しだけチューニング

phpMyAdminでDBの状態を見てみると赤字で調整を伺わす項目がある

23456

プログラム側の調整は単純には無理なのでDB側を少し調整してみることにする

今回は玄箱HGの実装メモリが128Mということもあり時間もかけたくないので、高度なチューンは考えないでMySQLTunerというツールmysqltuner.plを利用

$ wget http://mysqltuner.com/mysqltuner.pl
(目的の物が取得できなかったのでブラウザで持ってきた)
(以下で取得可能:https://github.com/major/MySQLTuner-perl)
$ wget https://github.com/rackerhacker/MySQLTuner-perl/archive/master.zip
(略)
$ unzip
master.zip
Archive: master.zip
d9eef7d75241e675469117b21b910e5b3d58dfa9
creating: MySQLTuner-perl-master/
inflating: MySQLTuner-perl-master/LICENSE
inflating: MySQLTuner-perl-master/README.md
inflating: MySQLTuner-perl-master/mysqltuner.pl
(ここまで)

$ perl mysqltuner.pl

 >> MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
 >> Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login:
Please enter your MySQL administrative password:
[!!] Attempted to use login credentials, but they were invalid.
hero@KURO-BOX:~$ perl mysqltuner.pl

 >> MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
 >> Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login:
Please enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.63-0+squeeze1
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 3M (Tables: 46)
[!!] InnoDB is enabled but isn't being used
[!!] Total fragmented tables: 12

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 11d 8h 34m 57s (214K q [0.219 qps], 3K conn, TX: 152M, RX: 25M)
[--] Reads / Writes: 54% / 46%
[--] Total buffers: 74.0M global + 3.1M per thread (151 max threads)
[!!] Maximum possible memory usage: 536.4M (432% of installed RAM)
[OK] Slow queries: 0% (2/214K)
[OK] Highest usage of available connections: 5% (8/151)
[OK] Key buffer size / total MyISAM indexes: 32.0M/1.3M
[!!] Query cache efficiency: 1.8% (860 cached / 47K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 15K sorts)
[OK] Temporary tables created on disk: 10% (1K on disk / 10K total)
[OK] Thread cache hit rate: 99% (18 created / 3K connections)
[!!] Table cache hit rate: 2% (64 open / 2K opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (573 immediate / 573 locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
 Add skip-innodb to MySQL configuration to disable InnoDB
 Run OPTIMIZE TABLE to defragment tables for better performance
 Reduce your overall MySQL memory footprint for system stability
 Enable the slow query log to troubleshoot bad queries
 Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
 *** MySQL's maximum memory usage is dangerously high ***
 *** Add RAM before increasing MySQL buffer variables ***
 query_cache_limit (> 1M, or use smaller result sets)
 table_cache (> 128)

Recommendations以降がお勧め設定値になる

上記はphpMyAdminの警告でテーブルキャッシュを128にした後のチェックであるがそれでも不足らしい
MySQLが使用メモリが多くて危険なのでバッファーを増やす前にメモリを増設とあるが少し増やして、

# vi /etc/mysql/my.cnf
table_cache = 192
query_cache_limit = 2M
# service mysql restart
・・・
# mysqladmin -u root -p variables
(略)

これでしばらく様子を見ることにする

尚、MySQLリファレンスマニュアルによると、サーバをチューニングする際に使用される最も重要な変数はkey_buffer_sizeと table_open_cacheの2つで、他の変数の変更を行う前にこの変数をあらかじめ適切に設定しておくこととある

ページ移動

  • ページ
  • 1
  • 2
  • 3
  • 4
  • 5

ユーティリティ

検索

エントリー検索フォーム
キーワード

過去ログ

Feed