tech_memo/linux
帯域測定 †
- Client側
[root@testserver13 ~]# iperf -c testserver11
------------------------------------------------------------
Client connecting to testserver11, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.122.113 port 60782 connected with 192.168.122.111 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 943 Mbits/sec
- 上記から、941〜943Mbps(117MByte/s)の性能が確認できる。理論最大値(1Gbps)に近い値が出ていることがわかる。
ソケット性能チューニング †
TIME_WAIT状態のソケットが多量に発生する場合 †
Apache †
CGIを使用した場合のTimeout時のステータスコード †
- サーバ遅延による、クライアントでのTimeoutは、通常408(Request Timed Out)だが、CGIスクリプトでは、このコードは使用されずに、504(Gateway Timed Out)が返される。全く意味が違うコードが返されてしまうので注意。
Apache proxyを使用したSSL通信 †
ksoftirqdのCPU使用率が高い †
ksoftirqdとは †
- ソフト割り込みを監視するカーネルスレッド
- ハードウェア割り込みと、ソフト割り込みには以下の種類があるあらしい
| ハードウェア割り込み | ソフト割り込み |
| イーサネットドライバ処理 | TCP/IPプロトコル処理 |
| SCSIホストバスアダプタドライバ処理 | SCSIプロトコル処理 |
| シリアルドライバ処理 | 端末制御処理 |
本問題で確認すべきこと †
- TCP/IP処理を複数コアで負荷分散しているか
- NICのoffloadingは有効か
- NICのドライバのバージョンは最新か
TCP/IP処理が複数コアで負荷分散されているかの確認方法 †
負荷分散されていない場合の対処 †
A) RHEL6系の場合(RHEL5でもカーネルバージョンを上げれば可能) †
- RPS/RFSを使用
# echo "f" > /sys/class/net/eth0/queues/rx-0/rps_cpus
# echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
# echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
/sys/class/net/eth0/queues/rx-0/rps_cpus は使用するCPUを指定します。
各コアを使用するかのフラグと2進数で各ビットを立て、16進数に変換します。
1,2コアを使用する場合は
2進数で 11 → 16進数に変換して3を設定。
1,2,3,4コアを使用する場合は
2進数で 1111 → 16進数に変換してfを設定。
B) RHEL5, 6共通 †
NICのoffloading †
その他 †
- NICのドライバのバージョンを最新にする(ドライバのバグでCPU負荷分散ができていないとか)
- PCIではなく、On boadにNICを差していないか？
NIC offload †
tcpdump †
- 22番ポートの受信情報
tcpdump src port 22
- 22番ポートの送信情報
tcpdump dst port 80
- 通信先ホストを限定
tcpdump host <HostName>
- -vでfull protocol decode。
tcpdump -v host <HostName>
- 受信情報のみ表示
tcpdump src host <HostName>
- 送信情報のみ表示
tcpdump dst host <HostName>
- 通信メッセージも表示
tcpdump -X host <HostName>
Port †
リモートホストがオープンしているPort番号を調べる †
ポートをオープンしているプロセスを調べる †
proxy例外設定 †
no_proxy=localhost,.example.com
wgetコマンド専用 proxy設定 †
tracertコマンド (宛先IPまでのルータの経路を知る) †
- root専用はtracertコマンド。
[root@myserver ~]# tracert testserver11
traceroute to testserver11 (192.168.122.111), 30 hops max, 40 byte packets
1 gwserver (192.168.0.1) 0.444 ms 0.435 ms 0.434 ms
2 testserver18x (10.99.99.204) 0.676 ms 0.676 ms 0.675 ms
3 testserver11 (192.168.122.111) 0.919 ms 0.920 ms 0.918 ms
- 一般ユーザはtracerouteコマンドを使う。(tracertとの違いは不明）
shishimaru@myserver% traceroute testserver11
traceroute to testserver11 (192.168.122.111), 30 hops max, 40 byte packets
1 gwserverx (192.168.0.1) 0.490 ms 0.475 ms 0.466 ms
2 testserver18x (10.99.99.204) 0.703 ms 0.684 ms 0.677 ms
3 testserver11 (192.168.122.111) 0.927 ms 0.883 ms 0.874 ms
Windowsマシンに対して、tracerouteの結果が返ってこない。 †
- LinuxのtracerouteはデフォルトでUDPを使用しているが、なぜかWindowsがUDPのResponseを返さない。ICMP(ping)を使用することでResponseが返ってくる。
[root@testserver10 ~]# traceroute -I 192.168.0.12
traceroute to 192.168.0.12 (192.168.0.12), 30 hops max, 60 byte packets
1 testserver18 (192.168.122.118) 0.135 ms 0.161 ms 0.163 ms
2 gwserver (10.99.99.228) 0.390 ms 0.396 ms 0.396 ms
3 192.168.0.12 (192.168.0.12) 0.616 ms 0.625 ms 0.624 ms
sshd †
- sshd_configパラメータの説明 (CentOS7.4)
ssh †
proxyサーバ経由でssh接続 †
HTTP 403のエラーが発生する場合 †
ログインが遅い †
- クライアントの名前解決が原因
- ssh サーバの /etc/hosts にクライアントの設定を書く
- DNSに問題がある場合、DNSを利用しないように、/etc/ssh/sshd_config に以下の設定を入れる．
UseDNS no
- GSSAPI 認証が遅い
- GSSAPI 認証を試みているので時間がかかる？ /etc/ssh/ssh_config に以下の設定を入れる
GSSAPIAuthentication no
- IPv6 が原因
- IPv6 で接続しようとしているか，IPv6 で名前解決しようとしているかで，できなくて時間がかかっている。
- IPv4(inet) のみを使用するよう、/etc/ssh/ssh_config に以下の設定を入れる．
AddressFamily inet
ssh時に「get_socket_address: getnameinfo 8 failed: Name or service not known」 †
ホストベース認証によるパスワードの省略 †
- サーバ側設定
- /etc/ssh/sshd_config
HostbasedAuthentication yes
- sshdサービス再起動
- ホストベース認証を許可するサーバを$HOME/.shostsに登録。
testserver testuser
testserver18
- 上記だと、testserverのtestuserでの接続を許可。testserver18も許可。testserver18はユーザ名を書いていないので、サーバ側と同じユーザからのみ許可。
- パーミッション変更
chmod 600 .shosts
- クライアント側の公開鍵を、サーバ側の.ssh/known_hostsに登録するために、一度だけサーバからクライアントにsshで接続する。
ssh testserver18 # from サーバ
SSH公開鍵を複数サーバに自動で追加する †
多段SSH (Gatewayサーバに指定コマンドを実行させる) †
sshコマンドでのポートフォワード †
sshの同時接続数 †
ssh/scp のhost key checkの無視 †
scp -oStrictHostKeyChecking=no file ip:/tmp
IP、サブネット(ネットワークアドレス)、ネットマスク設定 †
routing table †
- Destination : 送信元サブネット。送信元のサブネットと一致するものがあれば、自分で応答する。そうでないときはGateWay?に転送する。
- GateWay?(0.0.0.0以外) : Destinationがどれにも該当しないときの転送先。上記のこと。
- Iface : 送信先への応答する際のNIC
サーバ起動時の自動設定 †
- /etc/sysconfig/network-scripts/route-eth1に以下のように記述。下記例はtestserver18
224.0.0.1 dev eth1
192.168.10.0/24 dev eth1
- routing table
[root@testserver18 network-scripts]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
224.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.21.0 10.99.99.89 255.255.255.0 UG 0 0 0 eth0
192.168.0.0 10.99.99.228 255.255.255.0 UG 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.84.72.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0
0.0.0.0 10.99.99.254 0.0.0.0 UG 0 0 0 eth0
- testserver11で、下記のように実行するとエラーが出た
サーバ起動時の自動設定 その2 †
デフォルトゲートウェイ †
iptables †
仮想IP設定 †
MTU †
- Maximum Transmission Unit
- 確認方法
arp †
- トラブル
- eth0同士でつながっているマシンが数台あり、192.168.0.11をもっているマシンがAとB二台あった。ただし、Aはeth0, Bはeth1にそのアドレスが割り振られている。
- Cというマシンからpingしたときに先にAがarpをくれればいいが、Bが返すとpingは通らない。Bはeth0(IPは別物。通信はできる)で自分が192.168.0.11を(eth1に)持っていることを感知。
- Bはeth1のMACアドレスをこのとき返す。(リクエストIPのNICのアドレスを返す)
- CはBからarpが返ってきたので、Bにpingを送る。
- Bはeth0で受け取るが(設定にもよるが)返事はeth1で返そうとするが物理的につながっていないので返せない。
- Cからはpingがとおらないように見える(送れているけど還ってこない)。
- そもそもBに間違えてIPを設定してしまっている。が、IPの変更はできない状況とする。
- Bがarpを返すときに受信NICではなく指定IPのNICで返そうとする設定は以下
# set because eth1 has same IP address with silver servers
net.ipv4.conf.eth0.arp_ignore = 2 # default=0
net.ipv4.conf.eth1.arp_ignore = 2
- これでBがarpを返そうとしてもeth1では返せないので、CがBと通信をすることはなくなる。→ Aが必ず先にarpを返す。
sar †
最新の20件
2023-01-26
2022-11-11
2022-03-02
2022-02-03
2021-11-18
2021-11-11
2021-10-27
2021-10-04
2021-09-30
2021-08-24
2021-04-01
2021-02-25
2020-08-13
2020-05-22
2020-04-16
2020-04-15
2020-03-23
2020-03-12
2020-02-27
今日の20件
- counter: 1486
- today: 1
- yesterday: 2
- online: 1
