- 大量のファイル I/O の負荷の下で Windows Server 2008 R2 の SP1 または Windows 7 SP1 を実行しているコンピューターがフリーズします。
- Windows Server 2008 SP2 または Windows Vista の SP2 を実行しているコンピューターは、アプリケーションが NTFS スパース ファイルを使用するときを応答を停止します。
- ディスク I/O では、Windows の実行中にシステムがフリーズします。(これは、Windows Server 2012)
タグ: WindowsServer2008R2
-
NTFSのデッドロックに関するページ(メモ)
-
Bitnami Redmine のMySQLダンプ
Bitnami Redmine(Windows版)を使っていて、MySQLのダンプを取ろうと、mysqldumpコマンドを実行したが、接続エラーになる。mysqlコマンドでは、接続できているので、ユーザとパスワードと接続については、問題がないはず。いろいろと試した結果、以下のコマンドのときは成功したので、メモとして残しておく。
mysqldumpで成功したコマンド
mysqldump -u bitnami --password=password --all-databases --default-character-set=binary --port=3307 > dump2019mmdd.sql
これを実行すると、パスワードのくだりのところで、警告は出たが、MySQL Dumpは成功した。passwordの部分は、実際のパスワードに置き換える。
-
「データをトランザクション ログにフラッシュできませんでした」とWindowsのイベントログに記録される
Windows Server 2008 R2のイベントログを見ていたところ、「データをトランザクション ログにフラッシュできませんでした。障害が発生する可能性があります。」と記録されていた。
イベントID: 57 警告: データをトランザクション ログにフラッシュできませんでした。障害が発生する可能性があります。
該当する時間帯の前後のログを見てみると、Acronis 12で、vSphere6.0のESXi上の仮想マシンのバックアップを取得いる時間であることが判明。つまり、ESXi上の仮想マシンのスナップショットを取得中に発生しており、スナップショットの取得で、一時的に複数のディスクを所有しているように認識されたことにより、発生しているようだ。
特にサービスにも影響なく、バックアップの時間にだけしか出ていないため、対応する必要なし。
- 環境
- vSphere 6.0
- Windows Server 2008 R2(MSFC環境)
- Acronis 12(VMware側)
- 環境
-
ミスアライメントI/O
ミスアライメントとは
ストレージ側のブロックサイズにたいして、使用しているOSのアプリケーションデータの書き始めと終わりがストレージ側のブロックの中間から始まり、複数のブロックにまたがっている状態。
ミスアライメントI/Oが発生する状況
例えば、Windowsでは、iSCSIマウントしたストレージ側のブロックサイズが16Kのときに、フォーマットしたドライブのアロケートユニットサイズを4Kにしてしまうと、ミスアライメントI/Oが発生する。
解消するには、アロケートユニットサイズをストレージ側のブロックサイズと同じ値でフォーマットする。
ミスアライメントI/Oが発生していると、データの読み書きのパフォーマンス低下につながる。
-
システムバックアップからリストアしたところ、OSは正常起動したがOracleDBが自動で立ち上がらなくなった。
OracleがインストールされたWindowsサーバをシャットダウンし、システムバックアップを取得し、データファイルを保存している先のiSCSIディスクのバックアップも取得し、完全な静止点のバックアップを作成した。作業後、静止点のシステムバックアップからリストアを実施。リストア後、OS(Windows)は正常起動し、iSCSIについても問題はなかった。
しかし、OracleDBの接続確認したところ、「ORA-01034」が発生し、Oracle DBが正常に起動していなかった。Windowsのイベントログも確認したが、特に変なエラーはなし。唯一、Oracle DB起動時に権限系のエラーが出ていた。完全な静止点でのバックアップだったので、SCN番号も関係なし。しかも手動で`startup`すると正常にOracle DBが起動して使えるようになった。
試行錯誤で、Windows OSの再起動も試したが、事象が再現するだけ。アーカイブログモードもオフにしてみたが状況は変わらず。ドメインへの再参加も実施したが変わらず。いろいろと試したが状況は変わらず。ひとつひとつ切り分けていった結果、原因を特定した。
原因は、WindowsのOSが起動時に、iSCSIディスクがマウントされる前に、Oracle DBのサービスが起動していたため、データファイルがマウントできず、起動が失敗していた。
対応として、Oracle DBのサービスを開始遅延で設定。これで、先にiSCSIドライブがマウントされるようになり、自動起動するようになった。
今までは、たまたま起動順としてiSCSIのサービスが先に起動していただけ。それがイメージバックアップからのリストアがトリガーとなり、起動順番が変わり、Oracle DBが自動起動しなくなった、ということ。
-
Windows Server で同時にオープンできるセッション数を増やす
Windows Serverでオープンできるセッション数が足りなかったときに、オープンできるセッション数を増やす方法。
■コマンド
netsh int ipv4 set dynamicport tcp start=XXXX num=range
■MAXまで広げる場合
netsh int ipv4 set dynamicport tcp start=1025 num=64511
startは、ウェルノウンポートの後のである「1025番」を指定。
numは、65535から、ウェルノウンポートの1024を引いた64511。
なお、デフォルトで動的ポートの開始である49152番は、自由に割り当て可能なポート範囲として規定されているポートの開始番号。
-
Windows Server でオープンできるセッション数の調べ方(クライアントも可)
Windows Serverでオープンできるセッション数の調査は、コマンドで行う。
調査コマンド:
netsh int ipv4 show dynamicport tcp
IPv6を調査するときは、「ipv4」の部分を「ipv6」に変更する。UDPを調べるときは、「tcp」の部分を「udp」に変更する。
なお、Windows Server 2003以前のサーバは、レジストリ値を参照して調べる。
C:\Users\hoge>netsh int ipv4 show dynamicport tcp プロトコル tcp の動的ポートの範囲 --------------------------------- 開始ポート : 49152 ポート数 : 16384 C:\Users\hoge> C:\Users\hoge>netsh int ipv4 show dynamicport udp プロトコル udp の動的ポートの範囲 --------------------------------- 開始ポート : 49152 ポート数 : 16384 C:\Users\hoge> C:\Users\hoge>netsh int ipv6 show dynamicport udp プロトコル udp の動的ポートの範囲 --------------------------------- 開始ポート : 49152 ポート数 : 16384 C:\Users\hoge> C:\Users\hoge>netsh int ipv6 show dynamicport tcp プロトコル tcp の動的ポートの範囲 --------------------------------- 開始ポート : 49152 ポート数 : 16384 C:\Users\hoge>
-
Oracle DBの監査ログにシステム権限での接続が大量に記録される
Oracle DBの監査ログを調べて、変なアクセスや接続がないかどうかを調べた時の話。 監査ログに大量にログが記録されており、肥大化していた。 監査ログに、だいたい1分に2回くらいのシステム権限でのアクセスとSQL文の実行が記録されていた。 あまりにも気持ち悪いので、調べてみると、単に「システム権限で接続」しているセッションは、同一のサーバ内で「RHS.exe」が実行していることが分かった。
それで、この「RHS.exe」を調べると、MSFCのクラスタサービスが行っているリソースモニターのプロセスだった。
まとめると、
- Oralce DBの環境は、Windows Server 2008 R2 Enterpriseで、MSFCでクラスタを構成している。
- MSFCでは、Oracle Databaseをクラスタリングしている。
- MSFCでは、Databaseが正常稼働しているかどうかをチェックするために、キープアライブの確認を行っている。
- このキープアライブがシステム権限で接続しているので、そのログがOracle DBの監査ログに記録されており、ログが膨れ上がっていた。
わかってしまえば、なんということはない。ログはウザイが正常な動作でした。
-
「次の致命的な警告が生成されました: 10。内部エラーの状態は 10 です。」がイベントログに記録される
Windows Server 2008 R2 のシステムイベントログに、
「次の致命的な警告が生成されました: 10。内部エラーの状態は 1203 です。」
が記録されていた。見慣れないエラーなので、調査したところ、
このエラーはSSL/TLSで使用される443ポートに対して、 SSL/TLS以外の目的で
通信を行うと記録されるとのこと。たとえば、「http://localhost:443/」みたいに、SSL/TLSを使わずにアクセスすると、
イベントログにエラーが記録される。通信を受けただけで記録されるので、アタックなどでなければ、特に対応は必要なし。
-
Windows Server のDNSサーバにコマンドでレコードを追加する
WindowsのDNSサーバは、GUIで操作できるため、2,3個のレコード追加ならば、
GUIでプチプチと作業した方が楽。
10個以上のレコードを追加しようと思うと、めんどくさいのでコマンドを使って登録した方がよい。レコードを追加するコマンド
dnscmd DNSサーバ名(省略するとローカルホスト) /recordadd ゾーン名 ホスト名 RRの種類 RRデータ
- RRの種類は、AとかCNAME、NS、MXなどのこと。
- RRデータは、IPアドレス、ホスト名/ドメイン名のこと。RRの種類によって変わる。
例えば、ゾーン「ad.xenos.jp」に、gonbeというホスト名のAレコードを追加する場合。
dnscmd /recordadd ad.xenos.jp gonbe A 172.16.1.99
大量に追加する場合は、このコマンドをExcelにホスト名とIPアドレスを一覧化して、
うまいことコマンドを生成するとよい。