![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
네트워크 성능은 IT 환경의 나머지 부분의 일반적인 성능과 신뢰성에 상당한 영향을 미칠 수 있다. 다른 애플리케이션과 서비스가 네트워크 상에서 데이터를 기다리거나 클라이언트가 연결이나 정보 수신에 문제가 있는 경우에는 이런 문제들을 해결할 필요가 있다.
성능 문제 역시 애플리케이션과 환경의 신뢰성에 영향을 줄 수 있고, 이런 문제는 모두 네트워크 결함에 의해 촉발될 수 있으며, 어떤 경우에는 그 문제 자체가 네트워크 결함의 이유일 수도 있다. 네트워크 문제를 이해하고 진단하려면 우선 문제의 본질을 이해해야 하며, 보통 그 문제는 지연 또는 대역폭 문제와 관련될 것이다.
일반적으로, 네트워크 성능 문제는 기본 하드웨어에 연계되어 있는 경우가 많으며, 네트워크 환경의 실제 한계를 초과할 수는 없다. 모든 성능 문제는 보통 NFS 또는 웹 액세스와 같은 특정 프로토콜 또는 시스템과도 관련이 있다. 그러나 운영 체제 내부에서 그 문제를 진단하고 식별할 수 있으므로 알맞은 행동 방침을 결정할 수 있다.
본 기사에서는 성능 문제 식별과 관련된 다음과 같은 단계를 살펴본다.
- 기준선 성능 레벨 달성
- 문제의 정확한 위치 결정
- 통계 정보 획득
- 병목 지점 식별
성능 문제를 이해하고 진단하려면 우선 기준선 성능 레벨을 결정해야 한다. 우선 기준선 성능의 결정에 사용되는 두 가지 핵심 개념인 네트워크 지연과 네트워크 대역폭을 소개하겠다.
네트워크 지연은 대상으로 요청을 보낸 후 전송된 패킷을 대상에서 실제로 수신하기까지의 시간이다. 네트워크 성능에 대한 메트릭으로서, 지연이 증가한다는 것은 전송 중인 패킷 수가 용량을 초과하거나 데이터 송신자가 전송 또는 다시 전송하기 전에 기다려야 함을 나타내므로, 네트워크를 사용 중임을 표시하는 좋은 지표이다.
네트워크 복잡도와 패킷이 통과해야 하는 호스트 또는 게이트웨이 수가 증가할 때도 네트워크 지연이 발생할 수 있다. 지점 간의 케이블 길이 역시 지연에 영향을 미칠 수 있다. 먼 거리에서는 일반적인 동 케이블이 항상 광섬유 케이블 연결을 사용할 때보다 속도가 느리다.
또한, 네트워크 지연은 애플리케이션 지연과는 다르다. 네트워크 지연에서는 네트워크를 통한 패킷 전송만을 다루지만, 애플리케이션 지연은 애플리케이션에서 요청을 수신할 때부터 그 요청에 응답할 수 있을 때까지의 지연을 지칭한다.
대역폭은 특정 시간 동안 네트워크를 통해 전송될 수 있는 패킷 수의 척도이다. 대역폭은 전송 가능한 데이터의 양에 영향을 미치고, 한 호스트에 대한 데이터 전송량을 네트워크 연결에서 지원하는 실질적인 최대 전송량으로 제한하거나 다수의 동시 연결을 처리할 때의 총 전송 속도를 제한한다.
이론적으로는 네트워킹 인터페이스와 하드웨어를 변경하지 않는 한 네트워크 대역폭은 절대 바뀌면 안 된다. 네트워크 대역폭 내에서 주요 변수는 특정 시점에 네트워크를 사용 중인 호스트 수에 있다.
예를 들어, 1GB 이더넷 인터페이스는 다른 한 네트워크 호스트와 1GB를 송수신할 수 있고, 10개의 호스트와는 100MB, 100개의 호스트와는 10MB를 동시에 송수신할 수 있는 식이다. 물론, 실제로는 계속 이런 대역폭이 필요하지 않은 경우가 많다. 어떤 한 주기에 걸쳐 수많은 다른 호스트들로부터 수백 개의 작은 요청이 있을 것이므로, 한 서버의 사용 가능한 대역폭이 클라이언트 대역폭의 총합보다 훨씬 크게 나타날 수 있다.
네트워크 내부에 문제가 있는지 식별할 수 있으려면, 우선 사전에 가정한 사항을 기준으로 하는 기준선 성능이 있어야 한다. 이를 위해서는, 네트워크 애플리케이션 환경과 관련된 지연, 성능 및 테스트와 같은 다양한 매개변수를 검사하여 성능을 결정한 후 시간의 경과에 따라 이를 비교해야 한다.
기준선 네트워킹 테스트를 수행할 때는 통제된 상태에서 테스트해야 한다. 격리된(즉, 다른 네트워크 트래픽이 없는) 상태와 일반적인 네트워크 트래픽이 있는 상태에서 테스트를 수행하여 두 가지 기준선을 마련하는 것이 이상적이다.
- 격리된 모니터링의 경우, 네트워크에 다른 트래픽이 없을 때 서버와 하나 이상의 클라이언트 간 성능을 확인해야 한다. 이는 곧 다른 서비스를 종료하거나, 이상적인 상황으로서 서버와 클라이언트를 격리된 네트워크 환경에 두면 표준 네트워크 환경을 완전히 분리하지만 그 환경과 동일한 환경을 사용할 수 있음을 의미한다.
- 표준 모니터링의 경우, 클라이언트와 서버를 표준 네트워크에 연결하고 일반적인 백그라운드 트래픽은 작동시키되, 테스트 중인 서버의 트래픽을 제외한 모든 애플리케이션별 트래픽(예: 이메일, 파일 서비스, 웹 서비스)을 비활성화해야 한다.
실제 테스트 프로세스에서는 기준선 값을 결정하기 위해 수행할 수 있는 표준 도구와 테스트와 많이 있다.
Ping 도구는 모든 네트워크 관리자에게 네트워크 장치의 가용성과 지연을 검사하기 위한 기본 도구로 잘 알려져 있다. Ping 도구에서 해당 장치로 보내는 ICMP 패킷에 시스템이 응답하도록 구성된 경우 ping은 클라이언트와 서버를 포함한 대부분의 시스템에서 작동해야 한다. 본질적으로, ping은 장치로 에코 패킷을 보내고 장치에서 패킷의 내용을 다시 에코하기를 기다린다.
이 프로세스 중에 ping은 응답을 보내고 받는 데 걸리는 시간을 모니터할 수 있는데, 이는 에코 프로세스의 응답 시간을 측정하는 효과적인 방법일 수 있다. 가장 간단한 형태로서, 호스트로 에코 요청을 보내어 응답 시간을 확인할 수 있다(목록 1 참조).
목록 1. Ping을 사용하여 지연 결정
$ ping example PING example.example.pri (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.169 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.167 ms ^C --- example.example.pri ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.167/0.168/0.169/0.001 ms |
Ping 프로세스를 중지하려면 Control-C를 사용해야 한다. Solaris와 AIX®에서는 -s 옵션을 사용하여 둘 이상의 에코
패킷을 보내고 타이밍 정보를 얻어야 한다. 기준선 수치를 얻기 위해, (Linux®에서는) -c 옵션을 사용하여 개수를 지정할 수
있다. Solaris/AIX에서는 패킷 크기(기본값은 56바이트)와 보낼 패킷 수를 지정해야 하며, 그러면 프로세스를 수동으로 종료할 필요가 없다. 그러면 아래와 같이
타이밍 정보를 자동으로 추출할 수 있다(목록 2 참조).
목록 2. Solaris/AIX에서 ping을 사용할 때 패킷 크기 지정
$ ping -s example 56 10 PING example: 56 data bytes 64 bytes from example.example.pri (192.168.0.2): icmp_seq=0. time=0.143 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=1. time=0.163 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=2. time=0.146 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=3. time=0.134 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=4. time=0.151 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=5. time=0.107 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=6. time=0.142 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=7. time=0.136 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=8. time=0.143 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=9. time=0.103 ms ----example PING Statistics---- 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 0.103/0.137/0.163/0.019 |
목록 2의 예제는 네트워크를 사용하지 않는 시간 동안 실행되었다. 테스트 시간 중에 검사 중인 호스트나 네트워크 자체를 사용하고 있었다면 ping 시간이 상당히 늘어날 수 있다. Ping만으로 반드시 문제를 식별할 수 있는 것은 아니지만, ping을 통해 놓치지 말고 파악해야 할 문제가 있는지 여부를 빠르게 판단할 수 있을 때가 많다.
Ping에 대한 지원을 중단할 가능성이 있으므로, 어떤 호스트를 사용할 수 있는지 확인하는 도구로서 ping을 사용하기 전에 호스트에 액세스할 수 있는지부터 확인해야 한다.
평균 응답 시간을 추적한 다음 어디서부터 살펴봐야 할지 식별할 수 있도록, 일정한 주기에 따라 지속적으로 특정 호스트들 사이의 ping 시간을 추적하는 것이 이상적이다.
Sprayd 디먼과 연관된 spray 도구는 지정된 호스트로 대량의 패킷을 보내어 그 중 얼마나 많은 패킷이 응답을 받는지 확인한다. 네트워크 성능을 측정하기 위한 방법으로서, 이 방법에서는 연결 없는 전송 메커니즘을 사용하기 때문에 이를 성능 메트릭으로 삼으면 안 된다. 정의에 따라, 연결 없는 전송 기능을 이용해 보낸 패킷이 대상에 도달하리라는 보장이 없으므로, 어쨌든 통신에서는 패킷 삭제가 허용된다.
즉, 연결 없는 전송(UDP)에서 패킷을 삭제하는 경우 네트워크나 호스트를 사용 중이라서 패킷을 전송하지 못한다는 의미일 것이므로, spray를 사용하면 네트워크에 트래픽이 많이 있는지 여부를 알 수 있다.
Spray는 Solaris와 AIX 그리고 몇몇 다른 UNIX 플랫폼에서 사용할 수 있다. Spray를 사용하려면 (보통은 inetd를 통해) spray 디먼을 사용해야 할 수도 있다. Sprayd 디먼이 시작된 후, 호스트 이름을 지정하는 spray를 실행할 수 있다(목록 3 참조).
목록 3. Spray 사용
$ spray tiger
sending 1162 packets of length 86 to tiger ...
101 packets (8.692%) dropped by tiger
70 packets/sec, 6078 bytes/sec
|
이미 언급한 것처럼, 속도에 의존하면 안 되지만 삭제된 패킷 개수가 유용한 메트릭으로 활용될 수 있다.
네트워크의 대역폭 성능을 결정하는 최선의 방법은 시스템과 데이터를 주고받을 때 실제 속도를 검사하는 것이다. 서로 다른 많은 애플리케이션과 프로토콜에서 테스트를 수행할 때 사용할 수 있는 여러 가지 많은 도구가 있지만, 보통 가장 간단한 방법이 가장 효과적인 방법이다.
예를 들어, NFS를 사용하여 네트워크를 통해 파일을 전송할 때 네트워크 대역폭을 결정하려면 간단한 파일 전송 테스트 시간을 측정하면 된다. 간단한 테스트를
위해, mkfile을 사용하여 큰 파일을 작성한 다음(예를 들어, 2GB: $ mkfile 2g 2gbfile), 네트워크를 통해 다른 시스템으로 그 파일을
전송하는 데 걸리는 시간을 측정한다(목록 4 참조).
목록 4. 네트워크를 통해 다른 시스템으로 파일을 전송하는 데 걸리는 시간 측정
$ time cp /nfs/mysql-live/transient/2gbfile . real 3m45.648s user 0m0.010s sys 0m9.840s |
테스트를 여러 번 실행한 다음 전송 프로세스의 평균을 구해야 표준 성능을 제대로 파악할 수 있다.
목록 5에 있는 것과 같은 Perl 스크립트를 사용하여 복사 및 시간 측정 프로세스를 자동화할 수 있다.
목록 5. Perl 스크립트로 복사 및 시간 측정 프로세스 자동화
#!/usr/bin/perl
use Benchmark;
use File::Copy;
use Data::Dumper;
my $file = shift or die "Need a file to copy from\n";
my $srcdir = shift or die "Need a source directory to copy from\n";
my $count = shift || 10;
my $t = timeit($count,sub {copy(sprintf("%s/%s",$srcdir,$file),$file)});
printf("Time is %.2fs\n",($t->[0]/$count));
|
이 스크립트를 실행하려면 소스 파일과 소스 디렉토리의 이름을 입력하고, 작성할 사본 수를 선택적으로 입력한다. 그런 다음, 스크립트를 실행하여 시간을 구할 수 있다(목록 6 참조).
목록 6. Perl 스크립트 실행
$ ./timexfer.pl 2gbfile /nfs/mysql-live/transient 20 Time is 28.45s |
이 두 가지 모두 사용하여 기준선 수치를 구하고 정상 작동 중에 전송 성능을 확인할 수 있다.
일반적으로, 어떤 이유로 네트워크 관련 애플리케이션이 실패할 때만 네트워크 문제점을 식별할 것이다. 하지만, 그 문제점이 네트워크와 관련되어 있고 다른 곳에는 문제점이 없음을 식별하는 것이 중요하다.
우선, ping을 사용하여 시스템에 연결을 시도해야 한다. 시스템에서 ping 요청에 응답하지 않고 다른 네트워크 통신이 작동하지 않는 경우, 첫 번째 선택사항은 실제 케이블을 검사하고 모든 것이 그대로 연결되어 있는지 확인하는 것이다.
시스템에 여전히 연결할 수 있지만 ping 시간이 증가하는 경우에는 문제점이 어디에 있는지 결정해야 한다. 드물긴 해도, ping 시간의 증가가 시스템 상의 로드와 관련된 것일 수 있지만, 가끔 네트워크 관련 문제를 나타내기도 한다.
한 시스템의 ping 시간이 길다면 네트워크 상의 다른 시스템(다른 네트워크 스위치가 이상적임)에서 ping을 실행하여 문제점이 특정 시스템 또는 네트워크와 관련된 것인지 밝혀내야 한다.
Ping 시간이 예상보다 길 경우에는 사용 중인 네트워크에 대한 몇 가지 기본적인 통계 데이터 수집을 시작하여 문제점이 네트워크 인터페이스 또는 특정 프로토콜과 관련된 것인지 확인해야 한다.
Linux에서는 ifconfig 도구를 사용하여 몇 가지 기본적인 네트워크 통계 정보를 수집할 수 있다(목록 7 참조).
목록 7. ifconfig 도구를 사용하여 기본적인 네트워크 통계 정보 수집
$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:1a:ee:01:01:c0
inet addr:192.168.0.2 Bcast:192.168.3.255 Mask:255.255.252.0
inet6 addr: fe80::21a:eeff:fe01:1c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7916836 errors:0 dropped:78489 overruns:0 frame:0
TX packets:6285476 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11675092739 (10.8 GiB) TX bytes:581702020 (554.7 MiB)
Interrupt:16 Base address:0x2000
|
중요한 행은 RX와 TX로 시작하는 행으로서, 이들 행은 송신 및 수신된 패킷에 대한 정보를 표시한다. 패킷 값은 단순히 전송된 패킷 수를 나타낸 것이다. 위에 표시된 errors, dropped 및 overruns 값은 얼마나 많은 패킷이 특정한 종류의 결함을 나타냈는지 표시하는 것이다. 전송된 패킷 수와 비교하여 삭제된 패킷 수가 많으면 네트워크가 사용되고 있는 중임을 나타내는 것으로 볼 수 있다.
Netstat 도구를 사용하면 모든 플랫폼에서의 확장된 통계 정보를 구할 수도 있다. Linux에서는 이 도구가 TCP-IP 및 UDP 패킷 유형에 대한 패킷 전송과 같이 더 구체적인 기본 프로토콜 통계 정보를 제공한다. 이 정보에도 몇몇 기본적인 통계 데이터가 포함된다(목록 8 참조).
목록 8. Netstat 사용
$ netstat -s
Ip:
8437387 total packets received
1 with invalid addresses
0 forwarded
0 incoming packets discarded
8437383 incoming packets delivered
6820934 requests sent out
6 reassemblies required
3 packets reassembled ok
Icmp:
502 ICMP messages received
3 input ICMP message failed.
ICMP input histogram:
destination unreachable: 410
echo requests: 82
echo replies: 10
1406 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 1313
echo request: 11
echo replies: 82
IcmpMsg:
InType0: 10
InType3: 410
InType8: 82
OutType0: 82
OutType3: 1313
OutType8: 11
Tcp:
8361 active connections openings
6846 passive connection openings
1 failed connection attempts
164 connection resets received
33 connections established
8305361 segments received
6688553 segments send out
640 segments retransmitted
0 bad segments received.
676 resets sent
Udp:
126083 packets received
1294 packets to unknown port received.
0 packet receive errors
130335 packets sent
UdpLite:
TcpExt:
5 packets pruned from receive queue because of socket buffer overrun
6792 TCP sockets finished time wait in fast timer
5681 delayed acks sent
Quick ack mode was activated 11637 times
150861 packets directly queued to recvmsg prequeue.
74333 bytes directly in process context from backlog
9141882 bytes directly received in process context from prequeue
3608274 packet headers predicted
42627 packets header predicted and directly queued to user
77132 acknowledgments not containing data payload received
374105 predicted acknowledgments
2 times recovered from packet loss by selective acknowledgements
77 congestion windows recovered without slow start after partial ack
1 TCP data loss events
17 timeouts after SACK recovery
2 fast retransmits
8 retransmits in slow start
236 other TCP timeouts
1453 packets collapsed in receive queue due to low socket buffer
11634 DSACKs sent for old packets
2 DSACKs sent for out of order packets
2 DSACKs received
77 connections reset due to unexpected data
50 connections aborted due to timeout
TCPDSACKIgnoredNoUndo: 1
TCPSackShiftFallback: 23
IpExt:
InBcastPkts: 4126
|
Solaris와 다른 UNIX 변형에서 netstat에서 제공하는 정보는 플랫폼마다 다르다. 예를 들어, Solaris에서는 각 프로토콜에 대한 세부적인 통계 정보와 IPv4 및 IPv6 연결에 대한 개별 정보를 얻는다(목록 9 참조). 아래에 표시된 출력 결과는 일부가 잘린 내용이다.
목록 9. Solaris에서 netstat 사용
$ netstat -s
RAWIP rawipInDatagrams = 440 rawipInErrors = 0
rawipInCksumErrs = 0 rawipOutDatagrams = 91
rawipOutErrors = 0
UDP udpInDatagrams = 15756 udpInErrors = 0
udpOutDatagrams = 16515 udpOutErrors = 0
TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400
tcpRtoMax = 60000 tcpMaxConn = -1
tcpActiveOpens = 1735 tcpPassiveOpens = 54
tcpAttemptFails = 2 tcpEstabResets = 35
tcpCurrEstab = 2 tcpOutSegs =13771839
tcpOutDataSegs =13975728 tcpOutDataBytes =1648876686
tcpRetransSegs = 90215 tcpRetransBytes =130340273
tcpOutAck =151539 tcpOutAckDelayed = 5570
tcpOutUrg = 0 tcpOutWinUpdate = 31
tcpOutWinProbe = 86 tcpOutControl = 3750
tcpOutRsts = 63 tcpOutFastRetrans = 6
tcpInSegs =7548720
tcpInAckSegs =2882026 tcpInAckBytes =1648874900
tcpInDupAck =4413016 tcpInAckUnsent = 0
tcpInInorderSegs =415007 tcpInInorderBytes =367832646
tcpInUnorderSegs = 7650 tcpInUnorderBytes =10389516
tcpInDupSegs = 222 tcpInDupBytes = 74649
tcpInPartDupSegs = 0 tcpInPartDupBytes = 0
tcpInPastWinSegs = 0 tcpInPastWinBytes = 0
tcpInWinProbe = 0 tcpInWinUpdate = 2
tcpInClosed = 33 tcpRttNoUpdate = 660
tcpRttUpdate =2880379 tcpTimRetrans = 2262
tcpTimRetransDrop = 10 tcpTimKeepalive = 630
tcpTimKeepaliveProbe= 314 tcpTimKeepaliveDrop = 17
tcpListenDrop = 0 tcpListenDropQ0 = 0
tcpHalfOpenDrop = 0 tcpOutSackRetrans = 69348
...
|
모든 경우에 상위 레벨의 오류 패킷, 재전송 또는 삭제된 패킷 전송을 찾고 있으며, 이 모두는 네트워크가 사용 중임을 나타낸다. 전송 또는 수신된 패킷 수에 비해 오류 비율이 지나치게 높다면, 이는 네트워크 하드웨어의 결함을 나타내는 것일 수 있다.
NFS 연결과 사실상 대부분의 다른 네트워크 애플리케이션과 관련된 문제점을 검사할 때, 우선 (요청 처리 속도에 분명히 영향을 미칠) 높은 부하와 같이 시스템 상의 문제점과 관련된 문제가 아닌지 확인해야 한다. 프로세스를 식별하기 위해 가동 시간 및 ps를 이용한 간단한 검사를 통해 시스템을 얼마나 사용 중인지 알 수 있을 것이다.
또한, NFS 서비스에 의해 생성되는 NFS 통계를 확인할 수 있다. nfsstat 명령을 실행하면 NFS 서비스의 서버 및 클라이언트 쪽 모두에 대해 세부적인 통계 데이터가
생성된다. 예를 들어, 목록 10의 통계는 NFS 버전을 지정하기 위해 -s 및 -v 명령행 옵션을 사용하여 선택한
NFS 서비스의 서버 쪽에 대한 세부적인 NFS v3 통계를 보여준다.
목록 10.
-s 및 -v 명령행 옵션을 포함한 nfsstat 명령$ nfsstat -s -v3 Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 36118 0 0 0 0 410 0 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 75 0 0 0 0 0 0 Server NFSv3: calls badcalls 35847 0 Version 3: (35942 calls) null getattr setattr lookup access readlink 15 0% 190 0% 83 0% 3555 9% 21222 59% 0 0% read write create mkdir symlink mknod 9895 27% 300 0% 7 0% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 0 0% 0 0% 0 0% 0 0% 37 0% 20 0% fsstat fsinfo pathconf commit 521 1% 2 0% 1 0% 94 0% Server nfs_acl: Version 3: (0 calls) null getacl setacl getxattrdir 0 0% 0 0% 0 0% 0 0% |
badcalls 값이 높으면 서버로 잘못된 요청이 전송되고 있음을 나타내고, 이는 소프트웨어 문제 또는 결함이 있는 하드웨어로 인해 클라이언트가 올바로 작동하고 있지 않고 잘못된 요청을 제출하고 있음을 나타내는 것일 수 있다.
시스템에 대한 ping을 실행할 수 있지만 네트워크 성능이 여전히 문제인 경우에는 네트워크에서 성능 문제가 있는 곳을 확인해야 한다. 네트워크에서 라우터로 구분되는 서로 다른 세그먼트가 있는 대규모 네트워크에서는 traceroute 도구를 사용하여 두 시스템 사이의 경로에서 문제가 있는 특정 지점이 있는지 결정할 수 있다.
Ping 도구와 관련하여, traceroute 도구는 일반적으로 네트워크 패킷이 대상에 도달하기 위해 통과하는 각 라우터에 대한 ping 시간을 제공한다. 대규모 네트워크에서는 이것이 문제가 있는 곳을 격리하는 데 도움이 될 수 있다. 또한, 인터넷을 통해 패킷을 전송할 때 서로 다른 인터넷 서비스 제공업체(ISP) 사이에서 패킷을 전송하기 위해 서로 다른 지점에서 서로 다른 라우터가 사용되는 경우 발생할 수 있는 문제점을 식별하는 데도 이 도구를 사용할 수 있다.
예를 들어, 목록 11에 표시된 추적은 서로 다른 두 ISP를 이용하는 영국의 두 사무실 사이에서 이루어지는 것이다. 이 경우, 결함으로 인해 대상 시스템에 연결할 수 없다.
목록 11. 영국에 있는 두 사무실 간의 traceroute
$ traceroute gendarme.example.com traceroute to gendarme.example.com (82.70.138.102), 30 hops max, 40 byte packets 1 voyager.example.pri (192.168.1.1) 14.998 ms 95.530 ms 4.922 ms 2 dsl.vispa.net.uk (83.217.160.18) 32.251 ms 95.674 ms 30.742 ms 3 rt-gw1.tcm.vispa.net.uk (62.24.228.1) 49.178 ms 47.718 ms 123.261 ms 4 195.50.119.249 (195.50.119.249) 47.036 ms 50.440 ms 143.123 ms 5 ae-11-11.car1.Manchesteruk1.Level3.net (4.69.133.97) 92.398 ms 137.382 ms 52.780 ms 6 PACKET-EXCH.car1.Manchester1.Level3.net (195.16.169.90) 45.791 ms 140.165 ms 35.312 ms 7 spinoza-ae2-0.hq.zen.net.uk (62.3.80.54) 33.034 ms 39.442 ms 33.253 ms 8 galileo-fe-3-1-172.hq.zen.net.uk (62.3.80.174) 34.341 ms 33.684 ms 33.703 ms 9 * * * 10 * * * 11 * * * 12 * * * |
소규모 네트워크에서는 네트워크를 구분하는 라우터가 없을 것이므로, traceroute가 아무런 도움이 되지 못한다. Ping과 traceroute는 모두 문제점 확인을 위해 호스트에 연결할 수 있는 능력에 의존한다.
이제 UNIX 네트워크 성능 문제를 다루기 위한 몇 가지 지식과 기법을 익혔을 것이다.
UNIX 네트워크 성능 문제는 그 문제점이 보통 네트워크 전체에 퍼져 있을 때는 단일 시스템에서 식별하기 어렵다. 그러나 일반적으로 ping 및/또는 traceroute를 사용하여 네트워크 내부의 다른 지점에서 성능을 살펴봄으로써 시스템의 범위를 좁힐 수는 있다. 몇몇 지점을 출발점으로 정했으면, 다른 네트워크 도구를 사용하여 문제를 일으키고 있는 프로토콜이나 애플리케이션에 대한 세부 정보를 구할 수 있다. 본 기사에서는 기준선 정보를 얻기 위한 기본적인 방법과 문제를 정확히 파악하기 위해 사용할 수 있는 다른 도구들에 대해 살펴보았다.
교육
-
System Administration Toolkit: Network Scanning(Martin
Brown, developerWorks, 2007년 12월): 네트워크 스캐닝에 관한 팁을 확인할 수 있다.
-
Solve application problems with tracing(developerWorks): Truss, trace
및 유사한 도구의 사용법을 알아보자.
-
다수의 시스템 전체에서 동일한 명령을 사용하는 방법을 배우려면 System Administration Toolkit: Standardizing your UNIX command-line tools(Martin Brown, developerWorks, 2006년 5월)를 읽어보도록 하자.
-
시스템 관리 툴킷: 이 시리즈의
다른 파트를 확인해보자.
-
bash에서 프로그램하는 방법을 배울 수 있는 시리즈 기사인 Bash by example, Part 1: Fundamental programming in the Bourne again shell(bash)(Daniel Robbins, developerWorks, 2000년 3월), Bash by example, Part 2: More bash programming fundamentals(Daniel Robbins, developerWorks, 2000년 4월) 및 Bash by example, Part 3: Exploring the ebuild system(Daniel Robbins, developerWorks, 2000년 5월)을 확인하자.
-
유닉스와 리눅스를 함께 어울리게 만들기(Martin Brown,
developerWorks, 2006년 4월)는 일반적인 UNIX 배포 버전과 Linux를 함께 사용하기 위한 안내서이다.
-
시스템마다 다양한 도구를 사용한다. IBM Redbook인 Solaris to Linux Migration: A Guide for System Administrators에서 몇 가지 핵심 도구를 확인할 수 있다.
-
AIX and UNIX 입문: AIX와 UNIX 입문 페이지에서 자세한 정보를 볼 수 있다.
-
developerWorks AIX 및 UNIX 영역에는 수백 건의 유익한 기사와 초급, 중간급, 고급 사용자를 대상으로 하는 튜토리얼이 있다.
-
AIX Wiki: AIX와 관련된 기술 정보를 제공하는 협업 환경이다.
-
developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
-
Technology bookstore: 이 사이트에서는 각종 도서와 기타 기술 자료를 찾아볼
수 있다.
-
developerWorks
기술 행사 및 웹 캐스트: developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
-
팟캐스트: IBM 기술 전문가가 제공하는 유용한 정보를 볼 수 있다.
토론
-
다음과 같은 AIX 및 UNIX 포럼에 참여하자.
- AIX Forum
- AIX Forum for developers
- Cluster Systems Management
- IBM Support Assistant Forum
- Performance Tools Forum
- PowerVM Forum
- 기타 AIX and UNIX Forums
Martin Brown은 8년 넘게 기술 필자로 활약해왔다. Brown은 다양한 주제를 다루는 수 많은 책을 집필했고 기사를 작성했다. Brown은 펄, 파이썬, 자바(Java™), 자바스크립트, 베이직, 파스칼, 모듈라-2, C, C++, 레볼, gawk, 셸 스크립트, 윈도우(Windows®), 솔라리스, 리눅스, BeOS, 맥 OS X을 비롯하여 웹 프로그래밍, 시스템 관리, 통합에 이르리까지 다양한 개발 언어와 플랫폼을 경험했다. Brown은 마이크로소프트(Microsoft®) SME(Subject Matter Expert)이며 ServerWatch.com, LinuxToday.com, IBM developerWorks에 주기적으로 기고한다. Brown은 또한 컴퓨터월드, 애플 블로그, 기타 사이트에 주기적으로 블로그 기사를 올린다. 연락 주소는 Brown이 운영하는 웹 사이트를 참조하기 바란다.
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그