dd 명령으로 속도 측정시, bytes 설정값에 따라 write 속도 변화무쌍

안녕하세요. 날씨가 오락가락 하네요.  

아래와 같은 현상이 발생하여 질문드립니다. 


[ TEMP]#

[ TEMP]# dd if=/dev/zero bs=512 count=2048 of=/mnt/common/RWTEST01/test01.dat oflag=direct

2048+0 records in

2048+0 records out

1048576 bytes (1.0 MB, 1.0 MiB) copied, 13.6833 s, 76.6 kB/s

[ TEMP]# dd if=/dev/zero bs=1024k count=1 of=/mnt/common/RWTEST01/test01.dat oflag=direct

1+0 records in

1+0 records out

1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0103539 s, 101 MB/s

[ TEMP]#

[ TEMP]# dd if=/dev/zero bs=1024 count=1024 of=/mnt/common/RWTEST01/test01.dat oflag=direct

1024+0 records in

1024+0 records out

1048576 bytes (1.0 MB, 1.0 MiB) copied, 6.71534 s, 156 kB/s

[ TEMP]#




보시면 아시겠지만, 속도테스트  내용입니다. 


/mnt/common 이라는 디렉토리는 다른 머신에서 nfs mount  겁니다. 

즉, 서버 A B 두개가 있는데, /mnt/common 이란 폴더를 A  만들고, B  nfs  A:/mnt/common  mount  거죠.

A , B  개의 서버에서 자료를 공유하기 위해 + 프로그램 실행시 폴더 경로를 맞추려고 만든겁니다.


근데, 작업자가 B 서버 에서 A:/mnt/common  cfg 파일을 write 했는데, 느리다는 겁니다. 

cfg 파일이라 용량이 별로  큰데,  오래 걸리더라는 거죠. 


이상해서 dd 명령으로  봤더니, 왠걸... 초당 100kB  나오더라는 겁니다. 


저게, A 서버의 /mnt/common  NVMe 이고, 네트워크는 10g  동일망으로 물려있고, 동일 대역 IP 사용이라서, 네트워크나 disk  문제가 아닐  같아서 헤메다가, 혹시나 해서 bs값을 변경해 봤더니 , 

1024kB   번에 쓰면 속도가 101MB/s  나와버립니다.


뭐가 문제일까요? 혹은 키워드를 뭘로 검색하면 될까요? 어떤 뱡향으로 해결해 나가면 될까요?


짐작 가는 내용을 말씀해 주시면 도움이 되겠습니다.


이상입니다. 모두들 즐거운 하루 되시기 바랍니다. 감사합니다.




태그가 없습니다.
서버벨은 거의 모든 브랜드의 서버, 네트워크장비, 파트 및 옵션을 운영하고 있습니다.

Sponsored http://www.serverbells.com

서버벨은 HP, DELLEMC, IBM, LENOVO, CISCO, FUJITSU, ARISTA, ARUBA 등 전반적인 IT브랜드 신품/리퍼 재고를 유지 및 서버/스토리지/네트워크/옵션/파트 등을 전문적으로 운영하는 기업입니다.

자세히 보기

6개의 답변이 있습니다.

0 추천 | 약 한 달 전

해당 서버의 디스크및 설정을 체크 해봐야 할것 같네요. 100KB인대 속도가 느리다면 처리 과정이나 명령어등등을 봐야 할것 같습니다.

Reply

댓글 남기기

답변을 작성 하시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 약 한 달 전

NFS를 사용하여  서버 간에 공유되는 디렉터리에   쓰기 속도가 느려지는 문제는 여러 가지 요인으로 인해 발생할  있습니다. 


- NFS 구성: 서버 A의 NFS 서버 구성을 확인하여 성능이 최적화되었는지 확인하세요. 여기에는 NFS 버전, 마운트 옵션, 네트워크 설정 등의 설정이 포함됩니다.  서버 모두 동일한 NFS 버전과 호환 가능한 마운트 옵션을 사용하고 있는지 확인하세요.


- 네트워크 구성: 네트워크 인터페이스, 케이블  스위치를 포함하여  서버 모두의 네트워크 구성을 확인합니다. 모두 예상 속도로 작동하고 정체나 패킷 손실이 발생하지 않는지 확인하세요.


- 디스크 성능: 서버 A의 /mnt/common이 NVMe 스토리지에 있더라도 성능은 여전히 디스크 활용도, I/O 예약 또는 파일 시스템 구성과 같은 요인에 의해 영향을 받을  있습니다. 서버 A의 디스크 성능 메트릭을 모니터링하여 병목 현상이 없는지 확인합니다.


- NFS 클라이언트 구성: 서버 B의 NFS 클라이언트 구성을 확인하여 성능이 제대로 구성되었는지 확인합니다. 여기에는 읽기  쓰기 버퍼 크기와 사용 중인 NFS 버전과 같은 마운트 옵션이 포함됩니다.


- 파일 시스템 캐싱: 쓰기 성능을 향상하려면 NFS 클라이언트 측(서버 B)에서 파일 시스템 캐싱을 활성화하는 것이 좋습니다. 이는 데이터 일관성 요구 사항에 따라 actimeo, ac 또는 noac와 같은 마운트 옵션을 조정하여 수행할  있습니다.


- NFS 오버헤드: NFS는 네트워크 통신  프로토콜 오버헤드로 인해 로컬 파일 시스템 작업에 비해 약간의 오버헤드를 발생시킵니다. 블록 크기가 클수록 처리량이 향상될  있지만 작은 쓰기는 여전히 로컬 디스크 작업에 비해 상대적으로 느릴  있습니다.


- 파일 시스템 조각화: NFS 서버(서버 A)에서 파일 시스템 조각화를 확인하고 필요한 경우 조각 모음을 수행합니다. 조각화는 특히 소규모 무작위 쓰기의 경우 디스크 성능에 영향을   있습니다.


- 모니터링 도구: nfsstat, iostat, vmstat, netstat 등의 모니터링 도구를 활용하여 NFS  디스크 성능 지표에 대한 자세한 정보를 수집합니다. 이러한 측정항목을 분석하여 병목 현상이나 이상 현상을 식별하세요.


이러한 영역을 조사하고 필요에 따라 구성을 조정하면 NFS를 사용하여 서버 A와 B 간에 디렉터리를 공유할  쓰기 성능을 향상시킬  있습니다.

Reply

댓글 남기기

답변을 작성 하시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 약 한 달 전
  • 1.파일시스템이 ext4, zfs, xfs 인지 체크 필요

  • 2./etc/fstab 설정은 nfs 설정 후  자동 mount 하는 부분이고 defaults에서 주는 옵션은 (rw,nouser, auto, exec,suid) 속도를 높여주는게 아님

  • 3./etc/exports  설정은 sync(동기적 향상) , async( 비 동기적 향상) 로 async로 하게되면 네트워크 통신 항상은 될것 같습니다.

  • 4.disk iops에 따라 bs 또는 count를 적절하게 조저하면 될것 같습니다.

Reply

댓글 남기기

답변을 작성 하시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 약 한 달 전

1) bs=512 count=2048 

2) bs=1024k count=1

3) bs=1024 count=104

변화 무쌍할 수 밖에 없습니다.

1)번의 경우 512byte * 2048 = 1M / 512byte block을 2048번 액세스 하여 write 하는 것과

2)번의 경우 1M * 1 = 1M / 1M짜리 block을 1번 불러오는 것은 성능 차이가 날 수 밖에 없습니다.

dd의 경우 block size를 크게 할 수록 성능은 잘나옵니다.

그렇다고 높인다고 무조건 빨라지진 않으니 write하는 장치에 따라 적정한 값으로 설정해야 합니다.

 

nfs 설정 마운트할때 옵션을 체크해보세요. (/etc/exports, 또는 /etc/fstab)

  • rsize, wsize 수치를 조정

현재 값이 얼마로 설정되어 있는진 모르겠지만 

네트워크가 10g 사용하신다면 이 수치를 약간씩 늘리면서 테스트 해보세요.


Reply

댓글 남기기

답변을 작성 하시려면 로그인이 필요합니다.

로그인 회원가입

0 추천 | 약 한 달 전

네트워크를 통한 파일 시스템, SAN / DAS 등 Fibre 를 통한 파일 시스템 모두

block size 에 따라서 Throughput (MB/s) 는 많은 차이가 발생합니다.

일반적으로 block size 를 크게 할수록 좋은 성능을 나타내게 됩니다.

작은 size 의 block 으로 I/O 를 일으킬 때 서로 데이터를 주고 받기 위한 사전 신호, 사후 신호를

주고 받는데 많은 사이클을 사용하고,

이로 인해 실제 데이터를 보내는데는 많은 시간이 소요되지 않는데, 위 작업으로 최종적으로

데이터가 전송이 되는데까지는 시간이 많이 소요가 되는 거지요.

block size 가 클 경우에는 사전 신호 + 데이터 전송 (큰 block) + 사후 신호...

이런 식으로 전송이 되기 때문에 그만큼 같은 데이터를 전송하더라도 사전 & 사후 신호가 적게

잡아 먹게 되는 것입니다. 

SAN / DAS 와 달리 Network File System 의 경우에는 이 문제가 더 심해질 수 있습니다.

Packet 방식으로 데이터를 전송하다 보니 block 사이트가 적으면 적을 수록 

더욱더 성능이 나빠지는걸 볼 수 있습니다.

NFS (NAS 방식) 의 File System 을 사용할 경우에는 작은 파일을 자주 Acccess 하는 방식으로

사용하기에는 좋은 성능을 기대하기 어렵습니다. 

여러 곳에서 해당 File System을 공유하기 위함이 아니라면 작은 파일의 경우에는 SAN / DAS 방식을

사용하는 것을 권고 드려요.

Reply

댓글 남기기

답변을 작성 하시려면 로그인이 필요합니다.

로그인 회원가입

1st 5stars

0 추천 | 약 한 달 전

NFS라는건...

Network File System으로 네트워크를 통해서 블럭디바이스를 연결해서 사용하는 방식이 되겠고...

A 서버에서 공유하고 있는 디렉터리를 A 서버에서 접근할때는 로컬 디스크 개념으로 접근하지만...

B 서버에서 NFS를 통해서 A 서버에서 공유하고 있는 디렉터리를 접근할때는 네트워크 디스크 개념으로 접근하게 되겠고요.

네트워크를 통해서 접근할 때는 네트워크에 발생하는 다른 트래픽의 영향, 연결된 회선의 대역폭, 네트워크 인터페이스 카드의 상태, 송신 및 수신 버퍼 사이즈 등등의 영향을 받을 수 밖에 없겠고요.

전용 회선이 아닌 다른 장치들과 공유하는 회선을 통해 연결할 경우에는 네트워크 상황에 따라, 설정에 따라 다양한 결과가 나타날 수 있는게 아닐까 하는 생각이 드네요.


Reply

댓글 남기기

답변을 작성 하시려면 로그인이 필요합니다.

로그인 회원가입

답변 달기

답변을 작성 하시려면 로그인이 필요합니다.

로그인 회원가입

IT 솔루션 또는 하드웨어 도입을 검토 중 이신가요?

쉐어드IT 솔루션 상담실에서 믿을 수 있는 제품과 업체를 추천 받으실 수 있습니다.

솔루션 상담실 IT 컨시어지 서비스

네트워크 카테고리의 다른 질문들...

  • 4일 전
  • 댓글 : 약 22시간 전
  • 6일 전
  • 댓글 : 4일 전
  • 7일 전
  • 댓글 : 7일 전
  • 8일 전
  • 댓글 : 4일 전
  • 11일 전
  • 댓글 : 하루 전