サーバー管理者

システムおよびネットワーク管理者向けのQ&A

2
単一のLinuxサーバーで異なるファイルシステムを実行した場合のパフォーマンスへの影響
著書「HBaseの:決定的なガイド」のように述べています 単一のサーバーに異なるファイルシステムをインストールすることはお勧めしません。これは、異なるファイルシステムをサポートするためにカーネルがバッファキャッシュを分割する必要があるため、パフォーマンスに悪影響を与える可能性があります。特定のオペレーティングシステムでは、これがパフォーマンスに壊滅的な影響を与える可能性があることが報告されています。 これは本当にLinuxに当てはまりますか?バッファキャッシュが300 MBを超えるのを見たことがなく、最新のサーバーの多くはRAMがギガバイトであるため、異なるファイルシステム間でバッファキャッシュを分割しても問題はありません。私は何か他のものが欠けていますか?


7
SSHセッションを復元する
SSH経由でサーバーに接続してプロセスを作成しましたが、突然インターネット接続が切断されました。プロセスが進行していることは知っていますが、前のセッションを復元して進行状況を確認するにはどうすればよいですか?
13 ssh  debian  session 


2
「ip」コマンドを使用して、CentOS / RHEL 6での再起動後もIPアドレスエイリアスを保持します
私は常にifcfg-eth0:1エイリアスファイルを使用して追加のアドレスを作成しました。ただし、最近のrhelドキュメントでは、次のように記載されています。 iprouteパッケージのipコマンドは、同じインターフェースへの複数のアドレスの割り当てをサポートするようになったため、同じインターフェースに複数のアドレスをバインドするこの方法を使用する必要はなくなりました。 さらに、このサイトに関する多数の回答とコメントには、ifconfigが非推奨であり、代わりに「ip」を使用する必要があることが記載されています。ライブ変更に使用しても問題ありませんが、エイリアスファイルを使用せずに再起動後も変更を保持するにはどうすればよいですか?

3
管理ユーザーがワークステーションに重複した静的IPを割り当てないようにする
ローカルマシンの管理者であるユーザーが、サーバーで使用されているネットワークアダプターにIPを手動で割り当てるのを防ぐにはどうすればよいですか?一部のユーザーはこれを行っており、組織内のクラスター内のノードがダウンする重複IP問題が発生しました。

5
GUIDでGPO名を見つけますか?
広告ログを監視しています。誰かがADオブジェクトを変更すると、ログを見ることができますが、そのグループポリシーのGUIDのみが行に提供されました。 グループポリシーのGUIDが与えられた場合、gpmc.mscに表示された名前を取得することは可能ですか?(LDAPプロトコルを使用して取得することを意味します)


2
バリアを備えたSATAドライブの書き込みキャッシュの安全性
私は最近、SATAドライブに関する書き込みキャッシュ、NCQ、ファームウェアバグ、バリアなどについて読んでいますが、停電の場合にデータを安全に保つための最適な設定は何かわかりません。 私が理解したことから、NCQを使用すると、ドライブは書き込みを並べ替えてパフォーマンスを最適化し、どのリクエストが物理的に書き込まれたかをカーネルに通知できます。 書き込みキャッシュは、データが物理ディスクに書き込まれるのを待たないため、ドライブがリクエストをはるかに高速に処理できるようにします。 ここでNCQと書き込みキャッシュがどのように混在するかわかりません... ファイルシステム、特にジャーナリングされたものは、特定のリクエストがいつ書き留められたかを確認する必要があります。また、ユーザー空間プロセスはfsync()を使用して特定のファイルを強制的にフラッシュします。fsync()の呼び出しは、ファイルシステムがデータがディスクに書き込まれたことを確認するまで戻りません。 SASドライブでのみ見た機能(FUA、Force Unit Access)があります。これは、ドライブを強制的にキャッシュをバイパスし、ディスクに直接書き込みます。他のすべてについては、書き込みバリアがあります。これは、ドライブでキャッシュフラッシュをトリガーできるカーネルによって提供されるメカニズムです。これにより、重要なデータだけでなく、すべてのキャッシュが強制的に書き込まれるため、たとえばfsync()を使用すると、システム全体が悪用されます。 ファームウェアのバグがあるドライブ、またはデータが物理的に書き込まれた時期について意図的に存在するドライブがあります。 これを言って..ドライブ/ファイルシステムを設定する方法はいくつかあります:A)NCQおよび書き込みキャッシュを無効にするB)NCQのみを有効にするC)書き込みキャッシュのみを有効にするD)NCQと書き込みキャッシュの両方を有効にする バリアが有効になっていると思います。ところで、実際に有効になっているかどうかを確認する方法は? 電力損失の場合、ディスクへのアクティブな書き込み中に、ファイルシステムジャーナルとデータの両方でオプションB(NCQ、キャッシュなし)が安全であると推測します。パフォーマンスが低下する場合があります。 バリアまたはFUAを使用する場合、オプションD(NCQ + cache)は、fsync()を使用するファイルシステムジャーナルおよびアプリケーションにとって安全です。キャッシュで待機していたデータにとっては悪いことであり、それを検出(チェックサム)するのはファイルシステム次第であり、少なくともファイルシステムが(願わくば)不安定な状態になることはありません。パフォーマンスに関しては、より良いはずです。 しかし、私の質問は立っています...私は何かが欠けていますか?考慮すべき他の変数はありますか?これを確認できるツールがあり、ドライブが正常に動作することはありますか?

2
Sun Grid Engine huhohshdhjha
入力するとqstat -h、次のオプションが表示されます [-s {p|r|s|z|hu|ho|hs|hd|hj|ha|h|a}] show pending, running, suspended, zombie jobs, jobs with a user/operator/system/array-dependency hold, jobs with a start time in future or any combination only. h is an abbreviation for huhohshdhjha a is an abbreviation for prsh 世界は何ですかhuhohshdhjha????

3
キューディシプリンをデフォルトのpfifo_fastにリセットしますか?
私は一時的にレート制限されたキューの規律を設定し、それを少し後で削除しようとしています: # /sbin/tc qdisc add dev eth1 root tbf rate 600kbit latency 50ms burst 1540 # /sbin/tc qdisc del dev eth1 root 残念ながら、これによりキューの規則が完全に削除され、キューが削除された後に送信データ転送が機能しなくなります。 私はキューの規律をデフォルトにリセットできることを望んでいました: qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 …
13 linux  tc 

2
ext4でチェックサムデータの整合性を取得する方法
btrfsのようなファイルシステムでは、すべてのデータを調べてデータがファイルシステムのチェックサムと一致するかどうかを確認するスクラブを実行できます。 バックアップの前にext4のデータが正しいかどうかを確認したいと思います。 質問 ext4にはファイルシステムチェックサムがありませんが、同様のことができますか?

4
CentOS / dev / bus / usb構造
Ubuntu 12.04でusbデバイスを接続すると、devディレクトリツリーの下にusbデバイスが次のように追加されます。 /dev/bus/usb/001/001 私のCentOS 5では以下のように追加されました: /dev/bus/usb/devices/2-1.4/ lsusbでは、最初のデバイスのように/ devの下にusbデバイスを作成する必要があります。手動でリンクしようとするとそれを解決するために、OSは「No such file or directory error。」と表示しますが、ubuntuで同じディレクトリを問題なくリンクできます。 CentOS: ln -s /dev/bus/usb/devices/2-1.4/descriptors /sys/bus/usb/001/001 ln: creating symbolic link `/sys/bus/usb/001/001' to `/dev/bus/usb/devices/2-1.4/descriptors': No such file or directory ubuntuでは、/ dev / bus / usbの下に作成してもエラーは発生しません。 CentOSログでusbデバイスを接続すると、次のようになります。 Dec 5 12:20:18 2012 kernel: [74465.103460] usb 2-1.4: new high-speed USB device number …
13 centos5  usb 

2
SSDドライブのext3パーティションでの突然の停電後のファイルシステムの破損は「予期される動作」ですか?
私の会社は、内蔵SSDドライブのext3パーティションから起動する組み込みDebian Linuxデバイスを作成しています。デバイスは埋め込まれた「ブラックボックス」であるため、通常は外部スイッチを介してデバイスの電源を切るだけで無作法にシャットダウンされます。 ext3のジャーナリングは物事を整理するので、これは通常は問題ありません。そのため、ログファイルの一部が時々失われることを除いて、物事はうまく動き続けます。 ただし、最近、いくつかのハードパワーサイクルの後にext3パーティションが構造上の問題を発生し始めるユニットを見てきました。特に、ext3パーティションでe2fsckを実行すると、次のような多くの問題が見つかります。この質問の下部にある出力リストに表示されます。エラーの報告(またはパーティションの再フォーマット)が停止するまでe2fsckを実行すると、問題は解消されます。 私の質問は...たくさんの突然の/予期しないシャットダウンにさらされたext3 / SSDシステムでこのような問題を見ることの意味は何ですか? 私の考えでは、これはシステムのソフトウェアまたはハードウェアの問題の兆候である可能性があります。私の理解では、ext3のジャーナリング機能はこれらの種類のファイルシステムの整合性エラーを防ぐはずだと理解しているためです。(注:ユーザーデータはジャーナリングされていないため、ユーザーファイルが変更/欠落/切り捨てられる可能性があることを理解しています。具体的には、以下に示すようなファイルシステムメタデータエラーについて説明しています) 一方、同僚は、SSDコントローラーが書き込みコマンドを並べ替える場合があり、ext3ジャーナルが混乱する可能性があるため、これは既知/予想される動作であると述べています。特に、正常に機能するハードウェアとバグのないソフトウェアが与えられたとしても、ext3ジャーナルはファイルシステムの破損を不可能ではなく不可能にするだけであるため、時々このような問題が発生しても驚かないはずです。 私たちのどちらが正しいですか? Embedded-PC-failsafe:~# ls Embedded-PC-failsafe:~# umount /mnt/unionfs Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Invalid inode number for '.' in directory inode …


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.