認証が非常に遅い（sshとsuの両方で）
時間の経過とともにログインの試行が徐々に遅くなる、実稼働サーバーの1つに問題があります。およそ5日後、非常に遅くなり、いくつかの重要なプロセス/ cronエントリが正しく起動できなくなります。
サーバー情報：
ハードウェア：Dell R720 24 GBメモリ2 x Intel Xeon E502620 v2プロセッサー（合計24コア、ハイパースレッディングを含む）8 x 300GB 10K SASドライブ
OS：Red Hat Enterprise Linux 6.5
SSH経由でのログインで問題が発生し、「赤いニシン」の調査という長い道のりを歩み始めました。結局、私は次のことを行うことさえも非常に時間がかかることに気づきました：
[someuser#hostname] su -
Password:
上記のように 'su-'コマンドを実行する場合、ボックス自体で認証しようとしているだけなので、SSHをどのような形でも使用しないでください。
これは同じボックスで3週間連続で発生し、ローカルのみのログインも遅いことに気付いた（そしてテストしたいのですが）初めてです。
コンソールからログインすると、次のようになります。
hostname login: user
Password: # I enter the password and hit [enter]
久しぶりに….
[user@hostname ~] $
SSH経由でログインすると、次のようになります（冗長性がオンで、localhostログインを実行しています）。
[user@hostname ~]$ ssh -v root@localhost
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /usr/local/user/.ssh/identity type -1
debug1: identity file /usr/local/user/.ssh/identity-cert type -1
debug1: identity file /usr/local/user/.ssh/id_rsa type -1
debug1: identity file /usr/local/user/.ssh/id_rsa-cert type -1
debug1: identity file /usr/local/user/.ssh/id_dsa type -1
debug1: identity file /usr/local/user/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of Host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 1d:50:5e:a3:e4:63:d6:1d:d8:2c:85:07:95:81:c8:b6.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found
debug1: Next authentication method: publickey
debug1: Trying private key: /usr/local/user/.ssh/identity
debug1: Trying private key: /usr/local/user/.ssh/id_rsa
debug1: Trying private key: /usr/local/user/.ssh/id_dsa
debug1: Next authentication method: password
root@localhost's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
この時点で、しばらくの間スタックし、最終的には正常にログインします。
どんなポインタでも大歓迎です。これは私を壁に駆り立てています。
以下は、dmesg出力にも表示されます。さまざまなプロセス名に対して繰り返されます（「cifsd」だけでなく）
cifsd: page allocation failure. order:5, mode:0x20
Pid: 12913, comm: cifsd Not tainted 2.6.32-431.el6.x86_64 #1
Call Trace:
[<ffffffff8112f9e7>] ? __alloc_pages_nodemask+0x757/0x8d0
[<ffffffff8116e482>] ? kmem_getpages+0x62/0x170
[<ffffffff8116f09a>] ? fallback_alloc+0x1ba/0x270
[<ffffffff8116eaef>] ? cache_grow+0x2cf/0x320
[<ffffffff8116ee19>] ? ____cache_alloc_node+0x99/0x160
[<ffffffff8116ffe0>] ? kmem_cache_alloc_node_trace+0x90/0x200
[<ffffffff811701fd>] ? __kmalloc_node+0x4d/0x60
[<ffffffff8144feca>] ? __alloc_skb+0x7a/0x180
[<ffffffff81450fe0>] ? skb_copy+0x40/0xb0
[<ffffffffa014f57c>] ? tg3_start_xmit+0xa8c/0xd80 [tg3]
[<ffffffff81460354>] ? dev_hard_start_xmit+0x224/0x480
[<ffffffff8147bd0a>] ? sch_direct_xmit+0x15a/0x1c0
[<ffffffff81460858>] ? dev_queue_xmit+0x228/0x320
[<ffffffff8149a0d8>] ? ip_finish_output+0x148/0x310
[<ffffffff8149a358>] ? ip_output+0xb8/0xc0
[<ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0
[<ffffffff81499655>] ? ip_local_out+0x25/0x30
[<ffffffff81499b30>] ? ip_queue_xmit+0x190/0x420
[<ffffffff8112ff2f>] ? free_hot_page+0x2f/0x60
[<ffffffff814aee3e>] ? tcp_transmit_skb+0x40e/0x7b0
[<ffffffff814b1380>] ? tcp_write_xmit+0x230/0xa90
[<ffffffff814b1f00>] ? __tcp_Push_pending_frames+0x30/0xe0
[<ffffffff814a9663>] ? tcp_data_snd_check+0x33/0x100
[<ffffffff814ad261>] ? tcp_rcv_established+0x381/0x7f0
[<ffffffff8152873a>] ? schedule_timeout+0x19a/0x2e0
[<ffffffff814b5643>] ? tcp_v4_do_rcv+0x2e3/0x490
[<ffffffff814a130a>] ? tcp_prequeue_process+0x7a/0xa0
[<ffffffff814a4a2c>] ? tcp_recvmsg+0xacc/0xe80
[<ffffffff814c58ca>] ? inet_recvmsg+0x5a/0x90
[<ffffffff8105a625>] ? select_idle_sibling+0x95/0x150
[<ffffffff81449ab3>] ? sock_recvmsg+0x133/0x160
[<ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40
[<ffffffff81059216>] ? enqueue_task+0x66/0x80
[<ffffffff8105571d>] ? check_preempt_curr+0x6d/0x90
[<ffffffff81065c5e>] ? try_to_wake_up+0x24e/0x3e0
[<ffffffff81065e02>] ? default_wake_function+0x12/0x20
[<ffffffff8109b2b6>] ? autoremove_wake_function+0x16/0x40
[<ffffffff81449b24>] ? kernel_recvmsg+0x44/0x60
[<ffffffffa01fd7c9>] ? cifs_readv_from_socket+0x1a9/0x260 [cifs]
[<ffffffffa020b11d>] ? cifs_add_credits+0x5d/0x70 [cifs]
[<ffffffffa01fd8a7>] ? cifs_read_from_socket+0x27/0x30 [cifs]
[<ffffffffa01fda03>] ? cifs_demultiplex_thread+0x153/0xe10 [cifs]
[<ffffffff81065e02>] ? default_wake_function+0x12/0x20
[<ffffffffa01fd8b0>] ? cifs_demultiplex_thread+0x0/0xe10 [cifs]
[<ffffffff8109aef6>] ? kthread+0x96/0xa0
[<ffffffff8100c20a>] ? child_rip+0xa/0x20
[<ffffffff8109ae60>] ? kthread+0x0/0xa0
[<ffffffff8100c200>] ? child_rip+0x0/0x20
問題を発見しました（この投稿に感謝します https://stackoverflow.com/questions/8413975/10-second-delay-between-login-and-Shell-Prompt ）
問題は/etc/profile.d/zzzz-vamilocale.shファイルにあります。これは、vmプロパティから何かを読み取ろうとして、そこにスタックしています。このファイルを削除すると問題が解決します。
この問題をデバッグする方法：1.問題のあるユーザーとしてログイン2.「bash --login --verbose」を起動3.実行を停止する行を検索4. /etc/profile.dから1つのファイルでこの行を検索/
ログイン後にスローダウンを取得したら、技術的には、何が起きるかログイン間と最初のシェルプロンプトを確認する必要があります。
シェルのカスタムセットアップはクリエイティブなものを実行できます惨めな方法で失敗するいくつかの特別な条件下で-
実際にインタラクティブモードに入る前のログイン時のように、
またはDISPLAYがまだ定義されていない間。
この場合、ブロックしているものとtiming out、またはslowを行っているものを探します-
cartoon-esque automountingのように、すべてのホームディレクトリ、
現在および過去のすべての従業員の。
自分のものを除くもちろんです。
すでにマウントされています。
音が悪い？
番号。ほとんどの場合、簡単に見つけて面白いです。
ログイン後、シェルが表示されるまでの時間がメンテナンスタスクで使用されているため、シェルの速度が低下します。ただし、メンテナンスタスクは散発的にしか実行されません。そしてもちろん、それらは、月曜日の8:00以降の最初のログイン時の毎週のように、一度にすべて一緒に実行されるわけではありません。
思いがけないことがたくさんあります
示されているポイントは、ログイン後、シェルを表示する前に多くのことが発生する可能性があるということです。
Ubuntuでのログインが遅いように見える問題の1つのクラスは、その日のメッセージ-motdを生成することです。
これは、ログイン時に最初のシェルプロンプトの前に表示されるテキストです。
それは空であるか、単にいくつかの簡単な挨拶です。
ls -l /etc/update-motd.dをご覧ください
$ ls -l /etc/update-motd.d
total 28
-rwxr-xr-x 1 root root 1220 Jul 3 2012 00-header
-rwxr-xr-x 1 root root 1358 Jul 3 2012 10-help-text
-rwxr-xr-x 1 root root 149 Mar 19 2012 90-updates-available
-rwxr-xr-x 1 root root 147 Aug 8 2012 91-release-upgrade
-rwxr-xr-x 1 root root 142 Mar 19 2012 98-fsck-at-reboot
-rwxr-xr-x 1 root root 144 Mar 19 2012 98-reboot-required
-rwxr-xr-x 1 root root 1158 Jul 3 2012 99-footer
特に90-updates-availableは、この例では時々非常に遅いようです。そこで見つけたものを確認し、それらを/etc/update-motd.d.disabledに移動してテスト用に無効にする可能性があります。
遅い認証を調査する一般的な方法として、/etc/pam.confおよび/etc/pam.d/su（および/etc/pam.d/sshdなど）を使用して、ログインサービスが実行する認証の種類を確認します。システムログをチェックして、何かが記録されているかどうかを確認します（認証時からのログエントリを探します）。
あなたの場合、問題を明らかにするのはカーネルのログです。 「ページ割り当てエラー」メッセージは、システムの仮想メモリが不足していることを示します。一部のプログラムを強制終了するか、スワップ領域を増やしてください。