技術:2015年

2015年12月30日

年末ですね。サーバーをメンテナンスできますね!
ということで、デスクネッツを止めてリビジョンアップを行いました。

前回はこの記事 → 2014年05月05日:DeskNet's NEO バージョンアップ作業を行いました。

このときは、比較的大きなバージョンアップでした。その後もゴールデンウィークや夏休みなどを利用してパッチを当てたりしていました。
今回も特に大きな作業ではありませんが、メモ。

V3.0 R1.4 → V3.0 R1.6 になりました。
今まで最後のファイル更新でだいたい失敗していたので、不安でした。
しかし今回は何の問題も無く完了しました。

更新時のプロセスの利用確認をもっと厳密にやってくれればなー。っておもうんですけどね。
今まで、サービスを止めてても、プロセスをつかんで離さないためか、そこで更新エラーとなってしまうことがほとんどでした。

今回は問題無し。

ねんのため reindex もやっておきました。
参考
定常的なデータベース保守作業について

C:\Program Files\PostgreSQL\9.2\bin\reindex.exe -d [db名] -U postgres

5Gぐらいのデータベース容量で、概ね10分ぐらいでした。



stock_value at 18:21|この記事のURLComments(0)TrackBack(0)

2015年12月29日

すごく久しぶりに、WindowsUpdateを行いました。
このときに、WindowsUpdateの調子が悪かったので、コンポーネントをリセットし、最新のWinrodUpdateエージェントなどをインストールして解決しました。
2015年12月21日:Windows 2008 R2 Windows Update エラー。 80244019
2015年12月23日:Asus P9X79 を使用したPCが遅かったのでソフトウェアを最新にしたら解決したかも?メモ。

この辺の記事ですね。

そして無事にWindowsUpdateが完了すると、今度は tiworker.exe というプロセスが活発に活動してしまいました。このプロセスはCPUパワーを食うのか、すごくサーバーが遅くなってしまったのです。起動にも時間がかかるし、メニューをクリックしても、1分近く応答がありません。

上記の記事でも書いてありますが、RAIDの状況を確認したり、ホスト側でできることはすべて行いましたが、ホストに問題はなさそうに見えました。

そして遅いゲストと、遅くないゲストがありました。ゲスト側で確認すると、tiworker.exe がディスクアクセスを非常に多く行っています。
年末ということもあり、数日かけて様子をみながら調査を行っていました。

すると、上記記載の通り、チップセットなどのドライバーを最新にしたころ・・・それは遅くなったと感じてから3日後のことだったと思います。
このころには、すっかり元通りとなっていました。
WindowsUpdateを初期化したサーバーはWindows2008R2とWindows2012でしたが、その両方共が遅くなっていました。

おそらく、tiworker.exeが何か時間のかかる作業をしており、これには数日かかるのかもしれません。(そうだと僕は思っています)



stock_value at 13:25|この記事のURLComments(0)TrackBack(0)

2015年12月28日

僕はデータドライブを、Cから移動しています。この方がバックアップが取得しやすいからです。また以前はCドライブはSSDを利用しておりましたが、当時は容量が小さく、ドキュメントフォルダーなどはCから追い出さないと、容量が枯渇していました。これらの理由によってCドライブはOSのみ。それ以外はなるべくC以外のドライブへ。そのように運用していました。
※アプリによっては、Cドライブに置かれてしまうので、それはアレですが。

データドライブをすぐに ReFS にするのは、まだちょっと怖いので、データドライブをバックアップしているディスクについては、ReFS にしてみたいと思います。

以下のサイトを参考に
Win 8.1編: ReFSを利用可能にする

>1. 管理者権限でレジストリエディターを起動します。
>2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNTキーを開きます(ない場合は作成します)。
>3. MiniNTキー内にDWORD値「AllowRefsFormatOverNonmirrorVolume」を作成します。
>4. DWORD値「AllowRefsFormatOverNonmirrorVolume」の値のデータを「1」に変更します。

DWORDは32ビットでやりました。再起動しなくても、フォーマットの選択肢に出てくるようになりました。

速度は以下の通りでした。
■NTFS
-----------------------------------------------------------------------
CrystalDiskMark 5.1.0 x64 (C) 2007-2015 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
Sequential Read (Q= 32,T= 1) : 106.000 MB/s
Sequential Write (Q= 32,T= 1) : 60.190 MB/s
Random Read 4KiB (Q= 32,T= 1) : 1.319 MB/s [ 319.8 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 0.927 MB/s [ 241.9 IOPS]

■ReFS
-----------------------------------------------------------------------
CrystalDiskMark 5.1.0 x64 (C) 2007-2015 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
Sequential Read (Q= 32,T= 1) : 117.275 MB/s
Sequential Write (Q= 32,T= 1) : 69.335 MB/s
Random Read 4KiB (Q= 32,T= 1) : 1.310 MB/s [ 319.8 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 0.991 MB/s [ 241.9 IOPS]

※ちなみに100Gぐらいの、ものすーーーーごく古いドライブです。

僕の環境ではシーケンシャル関係は早くなりましたが、ランダム系はほとんど一緒ぐらいの結果となりました。

stock_value at 12:53|この記事のURLComments(0)TrackBack(0)

2015年12月27日

まず僕自身のミスでこのような事態となってしまいました。
ということでメモ。

linux integration servicesは、Hyper-Vとほとんど統合状態にあり、アップデートはされないと思っていました。
しかしKernelのバージョンアップに伴うのか、その辺はよくわかりませんが、LISもバージョンアップしているようでした。
もちろん、これらの機能を利用しているのか、正直分かりませんが・・・。

マニュアルに従って、インストールを行いました。僕はてっきり rpm をインストールするだけだと思ったのです。しかしすごく時間がかかりました。5分ぐらいでしょうか。

なんかよく分からないエラーも画面にでているし・・・。ということで、Ctrl+Cで強制終了してしまいました。

すると・・・。再起動するとKernel Panic となってしまい起動しませんでした。
原因としては、このLISをインストールするとき、裏ではKernelの再構築がおこなわれているようです。
そのため、中途半端なKernelが理由なのか、うまく起動しないという状態に。


以下の方法で解決しました。
まず起動時に 4...3...2...1... というカウントダウンのところでキーを押します。すると、過去のカーネルで起動することが可能です。

yum remove [起動しない最新カーネル] を行います。
例:
# yum remove kernel-2.6.32-573*
# yum remove kernel-debug-2.6.32-573*
# yum remove kernel-firmware-2.6.32-573*

上記アンインストール後は、/lib/modules/2.6.32-573.12.1.el6.x86_64/ フォルダが存在しないことを確認します。

念のため rpm も存在しないことを確認します。
# rpm -qa |grep kernel |grep 573

これで再起動を行います。
おそらく古いカーネルが第一候補になり、そのまま起動するはずです。

この状態で、再度 kernel を yum でインストールします。
僕の環境では yum update で最新カーネルが候補にでてきました。

最新カーネルのインストールを行います。※上記 yum で remove したカーネルが再度はいるはずです。

そしてもう一度再起動。
問題無く、起動するはずです。

そして新しいカーネルで起動したことを確認したら一番最初の手順にもどり、Linux Integration Services をインスト-ルします。
cat /etc/redhat-release で、バージョンの確認を忘れずに。ここで表示されるCentOSのバージョンに合わせて、LISをインストールします。

そして今度はちゃんと長時間待ちます。 ps -ef などで、通常と違うプロセスが動作していないか確認します。
インストール完了後は reboot して終了です。

これで kernel panic で起動しなくなった linux が復活しました。

stock_value at 12:15|この記事のURLComments(0)TrackBack(0)

2015年12月25日

ファイルのコピーをしていたら、Read Error となって、途中で止まってしまいます。何度やってもそのような感じ。

スナップショットは削除されました。CHKDSK を続行できません。
このドライブをスキャン中にスナップショット エラーが発生しました。やり直しできますが、この問題が引き続き発生する場合は、オフライン スキャンを実行して修正してください。

続いて以下のコマンドを。
chkdsk /scan /forceofflinefix

すると、以下のエラーが表示されました。やっぱりエラーはあったんですね
----------------------
ステージ 1: 基本のファイル システム構造を検査しています ...
"\System Volume Information\Dedup\ChunkStore\{B0C174CC-635B-4311-AFFE-8D3F80
FF65F1}.ddp\Stream\01020000.00000001.delete.log <0xa,0x56f6da>" で破損した基本フ
ァイル構造が見つかりました
... オフラインでの修復のためキューに挿入しました。
----------------------

とりあえずはここまで。
おそらく次回は、オフラインスキャンを行うことになるのだと思われます。


※僕としては chkdsk の理解はあまりアレですが、以下の通りと考えています。
1. オンラインでスキャン → chkdsk [Drive]
2. 解決できないときは、エラー箇所をキューに保管する → chkdsk /scan /forceofflinefix [Drive]
3. 上記キューにある箇所をオフラインでスキャン → chkdsk /offlinescanandfix [Drive]
[3]の作業においてのみ、サーバーが利用不可となります。

結局[3]の作業で時間がかかったように思いました。
本来であれば、 chkdsk /spotfix [Drive] を行えば早く終わったのかもしれません。


stock_value at 09:50|この記事のURLComments(0)TrackBack(0)

2015年12月23日

原因不明です。ひょっとしたら、遅くないかもしれません。
体感的に気になっているだかも・・・。

以下の構成です。
Xeon E2620 2GHz
Mem:16G
LSI(Avago)RAIDボードを搭載し、RAID1構成になっています。
Hyper-Vを動作させています。

正直なところなんら問題の無い構成です。むしろ贅沢な感じがしています。

仮想マシンはWindows2012や2008が動作していますが、ここにアクセスすると、ずいぶんともっさりとしています。
仮想PCに割り当てているメモリは大きくはありませんが、2Gとかそんな感じです。
それでも遅いのです。

クリックしても反応するまでに3秒とか。しかし決して処理が止まっているわけではなく、異常に遅いだけで、ちゃんと反応はあります。だから短気をおこして強制シャットダウンなどをする方がキケンです。
そのため放置ぎみに、ゆっくりと対応をしていました。

しかし問題です。大問題です。

ホスト側で、色々原因を調べたのですがいまいちはっきりしません。ホスト側でも空きメモリは十分にありました。
Diskアクセスをチェックしましたが、以下の通り、読み取りで230MB/s 、書き込みで90MB/S出ていました。早いかどうかはともかく、遅い状態にはなってないように思います。
Sequential Read (Q= 32,T= 1) : 233.310 MB/s
Sequential Write (Q= 32,T= 1) : 90.439 MB/s

ありがちな、Diskエラーなども考えられるので、整合性チェックなどを行いましたが、こちらも問題無し。

とりあえず他のチップセットなどのドライバーを最新版にしました。すると解決したようでした。・・・・なぜだろう。

Asusのサイトでは、以下のファイルがありました。
MEI_Win7-8-8-1_VER95151730-X79
さらにこの中に RAR ファイルがあったので、これを解凍。そしてインストールしました。

他にもチップセットドライバーをインストールしましたが、詳細は忘れてしまいました。。。10.XXのドライバーだったように思います。
こちらは、Asusサイトの物は若干古かったので、Intelからダウンロードしました。

これで問題の無い速度が出るようになりました。複合的に様々な作業をしていたので、どれが原因なのかはハッキリしません。

stock_value at 17:40|この記事のURLComments(0)TrackBack(0)

2015年12月22日

最近、スイッチ類についてネットを調べていることがたくさんありました。
その中で 2ch は一部の内容について気になるようなことが書かれているときもあります。

そのなかで、Realtekのことについて、あまりよく書かれていないことがありました。
僕としては、Realtekだからといって何かトラブルに遭遇したことはありません。(ないと思っています)
しかし一方で、Realtek のチップNICはサポートしていないという環境に遭遇したことはあります。だからRealtekはそういう製品なのかもしれません。

まず、新しい機能や高性能なのはIntelな感じがします。たとえば今では常識的ですが、当時はチーミングという、NICを束ねて利用するようなシチュエーションでは、Realtekは申し訳程度の機能で、通常利用は不可能なほど不安定でした。
一方で、IntelやBroadcomのNICは問題無く動作していました。

vmware などをテスト的に利用使用としても、当時は RealtekのNICではそもそも利用できないようなことがあったように記憶しています。

参考
独断と偏見のNIC選びをしてみる。

しかしたかがNICとは言っても、すげーたかい。なんであんなに高いんでしょうか。

stock_value at 18:53|この記事のURLComments(0)TrackBack(0)