2015年12月
2015年12月31日
今年は無気力。そんな1年でした。
2014年は1年単位の忙しいプロジェクトを行っており、楽しくもしんどい1年でした。
そのプロジェクトが終了し、残務作業をゆっくりとやっているような。そんな1年でした。
メールの返信などが遅くなっている自覚もありました。部下に仕事を任せてしまい、自分はラクしているのではないかという葛藤もありました。
もちろん仕事内容に手を抜くことはありませんが、色々と精神面での行き詰まりのようなものを感じていたのです。
今までよりも、ずっと価格よりもクオリティや知識を求められることが増えました。しかし僕は加齢による物なのか、昔ほどモチベーションが高くなく、新たな事を学ぶ姿勢について、気力が生まれません。
何が原因なのでしょうか。集中力が衰えているということでしょうか。それとも生活が充実していると思えるような事が多く、向上心が出てこないとか。
ふるさと納税を行いました。この辺についてはまた詳細を記載したいと思います。なんというか、今までは納税額を増やすためにも、収入の増加に力をいれていました。しかし最近は、こういった、同じ納税額でも少しでもお得になるようにという方向に努力をしています。
この辺も考え方が変わってきているのかもしれません。
2014年は1年単位の忙しいプロジェクトを行っており、楽しくもしんどい1年でした。
そのプロジェクトが終了し、残務作業をゆっくりとやっているような。そんな1年でした。
メールの返信などが遅くなっている自覚もありました。部下に仕事を任せてしまい、自分はラクしているのではないかという葛藤もありました。
もちろん仕事内容に手を抜くことはありませんが、色々と精神面での行き詰まりのようなものを感じていたのです。
今までよりも、ずっと価格よりもクオリティや知識を求められることが増えました。しかし僕は加齢による物なのか、昔ほどモチベーションが高くなく、新たな事を学ぶ姿勢について、気力が生まれません。
何が原因なのでしょうか。集中力が衰えているということでしょうか。それとも生活が充実していると思えるような事が多く、向上心が出てこないとか。
ふるさと納税を行いました。この辺についてはまた詳細を記載したいと思います。なんというか、今までは納税額を増やすためにも、収入の増加に力をいれていました。しかし最近は、こういった、同じ納税額でも少しでもお得になるようにという方向に努力をしています。
この辺も考え方が変わってきているのかもしれません。
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分ぐらいでした。
ということで、デスクネッツを止めてリビジョンアップを行いました。
前回はこの記事 → 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分ぐらいでした。
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が何か時間のかかる作業をしており、これには数日かかるのかもしれません。(そうだと僕は思っています)
このときに、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が何か時間のかかる作業をしており、これには数日かかるのかもしれません。(そうだと僕は思っています)
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ぐらいの、ものすーーーーごく古いドライブです。
僕の環境ではシーケンシャル関係は早くなりましたが、ランダム系はほとんど一緒ぐらいの結果となりました。
※アプリによっては、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ぐらいの、ものすーーーーごく古いドライブです。
僕の環境ではシーケンシャル関係は早くなりましたが、ランダム系はほとんど一緒ぐらいの結果となりました。
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 が復活しました。
ということでメモ。
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 が復活しました。
2015年12月26日
前にも書いたような気がするのですが、調べても出てこなかったので。
仕事や作業をするときに、不満をタラタラと必要以上にしゃべりながら作業をするという話を聞いたことがあります。
2名ほど、本当にひどいのがあったのですが、偶然にもその2名を僕は直接見たことがありません。
1件目。
PCのセットアップをする業者さんでした。僕の働いている会社は、電気工事などで関わっていました。お客さんがいない中での夜間作業だったのです。
PCのセットアップにはそこそこ時間がかかります。配線を綺麗にするのもそうですし、さまざまなソフトをセットアップする必要もあります。
これらの作業について、ずっと不満をグチグチ言っていたというのです。このときの不満の内容は、会社に対するもののほか、お客さんに対する不満もあったと言うことでした。
幸いなのは、お客様がその場にいないから、それを聞いていないということでしょうか。しかし不満があるなら、ぶつける先は多少なりともあるような気がします。特に営業さんとかね！
2件目。
お客さんが、PCを購入していただきました。そしてそのPCのセットアップにお伺いしたのです。そしてこのPCをセットアップするときに、「なぜこれを買ったのか」などという種類の文句をずっと言っていたというのです。その人は、その件で出禁になったようで、後日トラブルの時に僕がお伺いしましたが、、お客様よりそのことをやんわりと言われました。○○さんってすごいね。と。※外部業者なので僕は会ったことがありません
何よりもお客さんが購入したものにケチをつける神経が信じられません。確かに、これ！っていう驚くような微妙な製品を購入している場合はマレにあります。が、だいたいはコストと性能のトレードオフなので、安いからといってバカにすることはありませんし、逆に高いからすごいということもありません。淡々と作業していくだけです。ごくまれに、お店の人に勧められるがままに買って、意見を求められる時があります。そのときは正直こまるなー。
少なくとも仕事を遂行するうえで、気分を害するようなことはするべきではないという、しごく当たり前の事を思ったのでした。
仕事や作業をするときに、不満をタラタラと必要以上にしゃべりながら作業をするという話を聞いたことがあります。
2名ほど、本当にひどいのがあったのですが、偶然にもその2名を僕は直接見たことがありません。
1件目。
PCのセットアップをする業者さんでした。僕の働いている会社は、電気工事などで関わっていました。お客さんがいない中での夜間作業だったのです。
PCのセットアップにはそこそこ時間がかかります。配線を綺麗にするのもそうですし、さまざまなソフトをセットアップする必要もあります。
これらの作業について、ずっと不満をグチグチ言っていたというのです。このときの不満の内容は、会社に対するもののほか、お客さんに対する不満もあったと言うことでした。
幸いなのは、お客様がその場にいないから、それを聞いていないということでしょうか。しかし不満があるなら、ぶつける先は多少なりともあるような気がします。特に営業さんとかね！
2件目。
お客さんが、PCを購入していただきました。そしてそのPCのセットアップにお伺いしたのです。そしてこのPCをセットアップするときに、「なぜこれを買ったのか」などという種類の文句をずっと言っていたというのです。その人は、その件で出禁になったようで、後日トラブルの時に僕がお伺いしましたが、、お客様よりそのことをやんわりと言われました。○○さんってすごいね。と。※外部業者なので僕は会ったことがありません
何よりもお客さんが購入したものにケチをつける神経が信じられません。確かに、これ！っていう驚くような微妙な製品を購入している場合はマレにあります。が、だいたいはコストと性能のトレードオフなので、安いからといってバカにすることはありませんし、逆に高いからすごいということもありません。淡々と作業していくだけです。ごくまれに、お店の人に勧められるがままに買って、意見を求められる時があります。そのときは正直こまるなー。
少なくとも仕事を遂行するうえで、気分を害するようなことはするべきではないという、しごく当たり前の事を思ったのでした。
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] を行えば早く終わったのかもしれません。
スナップショットは削除されました。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] を行えば早く終わったのかもしれません。
