TUNING(7)

명칭
tuning - FreeBSD 에 있어서의 성능 튜닝

시스템 설정 - disklabel, newfs, tunefs, 스왑
disklabel(8) 또는 sysinstall(8) (을)를 사용해 하드 디스크상에 파일 시스템을 레이아웃 하는 경우, 디스크의 내주 트럭보다 외주 트럭 쪽이 훨씬 빠르게 데이터를 전송 할 수 있는 것을 의식하는 것이 중요합니다. 이 이점을 살리려면 , 작은 파일 시스템이나 스왑을 외주 트럭에 가까운 편으로부터 채워 가야 합니다. 보다 큰 파일 시스템은 내주에 가까운 편에 채워 가 가장 큰 파일 시스템을 마지막으로 합니다. 다음에 머신을 증강했을 때에 시스템 표준의 파일 시스템의 크기를 변경하지 않아도 되는 것 같은 크기로 결정하는 것이 중요합니다. 나는 대체로, 차례로 root partition에 128 M, 스왑에 1 G, /var 에 128 M, /var/tmp 에 128 M, /usr 에 3 G, 그리고 나머지를 /home 에 할당합니다.

전형적으로는 메인 메모리의 약 2 배의 스왑 스페이스를 준비해야 합니다. RAM 가 그만큼 많지 않은 경우는, 일반적으로 좀 더 스왑이 필요하겠지요. 256M 보다 작은 스왑을 설정하는 것은 추천할 수 없습니다. 스왑 파티션의 크기를 결정할 때는 장래의 메모리 증설을 생각해 두어야 합니다. 커널의 VM paging algorithm는, 스왑의 크기가 메인 메모리의 적어도 2 배 있는 경우에 최고의 성능이 나오도록(듯이) 츄 되고 있습니다. 스왑을 작게 너무 작게 하면(자), VM 페이지 주사 코드가 효율적으로 움직이지 못하게 됩니다. 메모리를 한층 더 추가했을 때도 같습니다. 마지막으로, 복수의 SCSI 디스크 (혹은 다른 콘트롤러상에 있다 복수의 IDE 디스크)를 갖춘 대규모 시스템에 대해서는, 각각의 드라이브 (최대 4 드라이브)에 스왑을 두는 것을 강하게 추천 합니다. 각 드라이브상의 스왚 파티션이 거의 같은 크기가 된다 같게 해 주세요. 커널은 임의의 크기를 취급할 수가 있습니다만, 내부의 데이터 구조는 최대의 스왚 파티션의 것의 4 배의 크기가 되어 버립니다. 스왚 파티션을 대체로 같은 크기로 하는 것으로, 커널은 최적인 방법으로 스왑 공간을 N 대의 디스크에 대해 스트라이핑 합니다. 약간의 너무 하고 를 신경쓸 필요는 없습니다. 스왑 공간은 UNIX 하지만 우아하게 동작하기 위한의 것입니다. 평상시 그만큼 스왑을 사용하지 않아도, 프로그램의 크래쉬로 강제적으로 리부트해 버리기 전에, 회복 작업을하기 위한 시간 벌기가 됩니다.

/var 파티션을 얼마나의 크기로 할까는, 그 머신을 무엇에 사용할까라고 하는 것에 크게 의존합니다. 이 파티션은 주로 메일 박스나 프린트 spool, 로그 파일의 보존 장소에 사용됩니다. /var/log (을)를 다른 파티션으로 하는 사람도 있습니다 (그러나, 파티션 ID 를 소비하지 않는 편이 좋은 극단적인 경우는 예외입니다). 메일 서버나 프린트 서버, 혹은 방문수가 매우 많은 Web 서버로서 머신이 동작한다면, 지극히 큰 파티션 – 아마 1 기가바이트 이상 – 를 작성하는 것을 생각해야 하는 것이지요. 로그 파일의 보존에 필요한 크기는, 작게 추측해지고 쉽상입니다.

/var/tmp 의 크기는, 임시 파일의 종류가 얼마나 사용될 필요가 있을까로 정해집니다. 최악이어도 128M 로 하는 것을 추천 합니다. 또 sysinstall 는 /tmp 디렉토리도 작성합니다. 임시 파일 area 전용에 1 개의 파티션을 할당하는 것은 중요해, 2 개의 이유가 있습니다: 크래쉬시의 파일 시스템의 파괴의 가능성을 줄이는 것과 [/var]/tmp (을)를 가득하게 해 버린다 같은 크래쉬 프로세스가, 한층 더 중요한 하부조직 (메일이나 로그등 )에 영향을 줄 가능성을 줄이기 (위해)때문입니다. [/var]/tmp 하지만 가득하게 되어 버리는 것은 자주 있는 문제입니다.

이전에는 /tmp (와)과 /var/tmp 의 사이에는 차이가 있었습니다만, /var (와 /var/tmp) 의 도입에 의해 프로그래머는 몹시 혼란해, 오늘로는 양쪽 모두가 아무렇게나 사용되고 있습니다. 즉 이 2 개(살)은 실제로는 구별할 수가 없습니다. 따라서, 1 개의 텐포라리디레크트리인 만큼 하고 해, 다른 tmp 디렉토리에서 여기에 소프트 링크하는 것은 의미가 있습니다. 어떻게 /tmp (을)를 취급했다고 해도, 그것이 root partition에 있는 것은 바람직하지 않을 것입니다. 가득하게 되거나 크래쉬나 리부트에 의해 파괴된다 가능성이 있기 때문입니다.

/usr 파티션은 시스템을 서포트하기 위해서 필요한 파일의 대부분을 가지고 있어 그 서브 디렉토리 /usr/local 하 ports(7) 계층으로부터 인스톨 되는 파일의 대부분이 놓여집니다. ports 를 그다지 사용하지 않고, 시스템의 소스 (/usr/src) (을)를 보관 유지할 생각이 없으면 /usr (은)는 1 기가바이트로 충분하겠지요. 그러나, 대량의 ports (특히 윈도우 매니저나 Linux 에뮬레이션 되는 바이너리)를 인스톨 하는 경우는, 적어도 2 기가바이트의 /usr (을)를 추천 합니다. 게다가 시스템의 소스를 보관 유지할 생각이면, 3 기가바이트의 /usr (을)를 추천 합니다. 이 파티션에 대해서 필요한 area의 크기를 과소평가 하지 말아 주세요. 이것은 완만하게 성장해, 놀라게 해지게 됩니다 !

/home 파티션은 유저 고유의 데이터를 보관 유지하는데 사용됩니다. 나는 대체로 디스크의 나머지를 사용합니다.

왜 파티션을 자르겠지요 ? 1 개(살)의 큰 / 파티션을 만드는 것만으로 좋은 것이 아닐까요 ? 너무 그러면 작지 않는가 제발 신경쓸 필요는 없는데 ! 네, 그 생각이 좋지 않는 것은, 몇개인가 이유가 있습니다. 1 개째는, 각각의 파티션은 운용상의 성격이 다릅니다만, 그것들을 분리하는 것으로 파일 시스템에 대해 그 성격에 적절한 츄를 하는 것이 가능하게 되기 때문입니다. 예를 들면 root partition나 /usr 파티션은 거의 읽기이며, 거의 기입이 없습니다. 한편으로 /var (이)나 /var/tmp 에 대해서는 대량의 읽기나 기입이 있겠지요. 시스템을 잘 분할하는 것으로, 기입이 많은 파티션의 파괴에 밤피해가, 거의 읽을 보고의 파티션에 이르지 않게 합니다. 더해, 기입이 많은 파티션을 디스크의 구석 (즉 파티션 테이블에 대해, 정말로 큰 파티션의 뒤가 아니고, 앞쪽) (분)편에 두는 것으로, 그 파티션에 대해 성능이 향상합니다. 보다 큰 파티션에 대해서도 입출력 성능이 필요한도 확실합니다만, /var (을)를 디스크의 구석에 두면(자) 큰 개선이 가능해요에 대해, 거대한 파티션을 디스크의 구석에 두어도 그만큼 성능의 개선에는 연결되지 않습니다. 최후는 안전성에 관련되는 것입니다. 작고, 간결한, 본질적으로 읽을 보고의 root partition로 하는 것으로, 크래쉬를 살아남을 찬스를 크게 할 수가 있습니다.

시스템을 올바르게 분할하는 것으로, newfs(8) (이)나 tunefs(8) 에게 주는 파라미터를 츄 하는 일도 가능하게 됩니다. newfs() 의 튜닝에는 한층 더 경험이 필요합니다만, 상당한 성능 개선으로 연결됩니다. 비교적 안전하게 츄 할 수 있는 3 개의 파라미터가 있습니다: blocksize, bytes/inode, cylinders/group 입니다.

FreeBSD (은)는 8K 또는 16K 의 파일 시스템 블록 사이즈를 사용했을 때에 최고의 성능을 얻을 수 있습니다. 디폴트는 16K 이며, 대부분의 어플리케이션으로 좋은 결과가 됩니다만, 큰 파일에 랜덤 억세스 하는 어플리케이션 (데이터 베이스 서버 소프트웨어등 )(은)는 예외입니다. 이러한 어플리케이션에서는, 작은 블록 사이즈로 좋은 결과가 되는 경향이 있습니다만, 최근의 디스크의 특성에 대해서는, 작은 블록 사이즈의 사용은 고려할 만하지 않을 것입니다. 16K 보다 큰 블록 사이즈를 사용하면(자) 버퍼 캐쉬의 단편화를 불러, 성능이 저하합니다.

디폴트는, 다대한 inode 를 필요로 하는 파일 시스템이나, 다대한 소파일을 보관 유지하는 것을 의도한 파일 시스템에는 향하지 않을지도 모릅니다. 이러한 파일 시스템은, 8K 또는 4K 의 블록 사이즈로 작성되어야 합니다. 이것은 또, 작은 fragment 사이즈를 지정할 필요가 있습니다. 항상 블록 사이즈의 것 1/8 의 fragment 사이즈로 하는 것을 추천 합니다 (다른 fragment 사이즈의 비율에서는 그다지 테스트되고 있지 않습니다). 이 경우의 newfs(8) 옵션은 “newfs -f 1024 -b 8192 ...” 되겠지요.

큰 파티션에, 데이타베이스 파일과 같은 소수의 큰 파일을 둔다면, bytes/inode 의 비율을 늘릴 수가 있습니다. 이것은, 그 파티션의 inode 의 수 (파일이나 디렉토리의 최대의 수)를 줄입니다. inode 의 수를 줄이는 것으로, 크래쉬 후의 fsck(8) 에 의한 수복 시간을 큰폭으로 줄일 수가 있습니다. 정말로 이 파티션에 큰 파일을 두므로 없는 한, 이 옵션을 사용하지 말아 주세요. 빈area가 대량으로 있는데 파일을 수용할 수 없게 될지도 모릅니다. bytes/inode 는, 32768 인가 65536 이나 262144 로 하는 것이 추천 됩니다. 좀 더 큰 값으로 할 수가 있습니다만, fsck(8) 에 의한 수복 시간을 늘리는 것만으로 짊어진다. 예를 들면, “newfs -i 32768 ...” (와)과 같이 해 값을 줍니다.

tunefs(8) (은)는 파일 시스템을 한층 더 츄 하는데 사용할 수 있습니다. 이 명령은, 싱글 유저 모드로 실행할 수가 있어 파일 시스템의 재포맷은 불필요합니다. 그러나, 아마 가장 잘못해 사용되고 있는 프로그램이지요. 많은 사람은 파일 시스템의 이용 가능한 빈area를 늘리려고, min-free 비율을 0 으로 설정합니다. 이것은 파일 시스템의 맹렬한 단편화로 연결되므로, 추천 되지 않습니다. 여기서, 유일 정말로 가치가 있다 tunefs(8) 의 옵션은, “tunefs -n enable /filesystem” (으)로서 softupdates (을)를 유효하게 하는 것입니다 (주의: FreeBSD 4.5 이후에서는 newfs(8) 에 -U 옵션을 주는 것으로 softupdates 를 유효하게 할 수가 있습니다. 그리고 sysinstall(8) (은)는, 루트 이외의 파일 시스템의 softupdates 를 표준으로 자동적으로 유효하게 합니다). softupdates 는 메타데이타의 성능, 주로 파일의 작성과 삭제의 성능을 극적으로 개선합니다. 대부분의 파일 시스템으로 softupdates 를 유효하게 하는 것을 추천 합니다. 그렇지만, 파일 시스템으로 softupdates 를 사용하는지 어떤지 판단할 때에 조심해야 할 2 개의 제한이 있습니다. 1 개째는, softupdates 는 크래쉬시에 있어서의 파일 시스템의 일관성은 프로텍션합니다만, 미반영의 물리 디스크 기입보다 몇초인가 (1 분이 될 수도 있습니다! ) 아마 늦는 것 입니다. 크래쉬 했을 경우, 보다 많은 성과가 사라져 버릴지도 모릅니다. 2 개째는, softupdates 는 파일 시스템 블록을 해방하는 것을 늦춘다 그렇다고 하는 것입니다. 어느 파일 시스템 (예를 들면 루트 파일 시스템)이 만배 가까이의 때에 그에 대하는 대규모 갱신, 예를 들어 “make installworld” (을)를 하면(자), 빈area를 다 써 버려 갱신이 실패해 버리는 일이 있습니다. 그 때문에 표준적인 인스톨에서는 루트 파일 시스템의 softupdates 를 유효하게 하지 않습니다. 루트 파일 시스템은 분별없게 기입해지지 않으므로, 성능상의 손실은 없습니다.

mount(8) 실행시의 몇개의 옵션은 파일 시스템을 츄 하는데 도움이 됩니다. 가장 분명해, 게다가 가장 위험한 것은 async 입니다. 이것은 결코 사용하지 말아 주세요. 몹시 위험합니다. 비교적 위험도가 낮고, 보다 도움이 된다 mount(8) 의 옵션은 noatime 입니다. 통상 UNIX 파일 시스템은, 파일이나 디렉토리에 액세스가 어늘었을 경우는 항상, 그 최종 액세스 시각을 갱신합니다. FreeBSD 그럼, 이 동작은 지연 기입으로 행해져 통상은 대단한 부하로는 되지 않습니다. 그러나, 대량의 파일이 연속해 액세스 되었을 경우, 버퍼 캐쉬가 액세스 시각의 갱신으로 오염되고 큰 부하가 됩니다. 예를 들면, 고부하의 web 사이트나 대량의 독자를 거느리는 뉴즈서바 그럼, 이 mount(8) 의 옵션으로 큰 파티션에 있어서의 액세스 시각의 갱신을 정지하는 것을 생각됩니다. 근거도 없고, 모든 장소에서 액세스 시각의 갱신을 정지하지 말아 주세요. 예를 들면, /var 파일 시스템은, 관습적으로 메일 박스를 보관 유지해, 신규 메일의 메일 박스중의 유무 판정에 atime ( 및 mtime)가 사용됩니다. 읽기 전용 파티션, / (이)나 /usr 그럼, atime 를 온으로 해 두는 것이 좋을 것입니다. 시스템 유틸리티에는, atime 필드를 사용하는 것이 있으므로, / 그럼 특히 유용합니다.

디스크의 스트라이핑
큰 시스템에서는, 몇개의 드라이브의 파티션을 서로 스트라이핑 해, 전체적으로 거대한 파티션을 만드는 일도 있습니다. 스트라이핑은, 입출력 조작을 복수의 디스크에 배분하는 것으로 파일 시스템의 성능을 향상시킬 수가 있습니다. vinum(8) 및 ccdconfig(8) 유틸리티는, 신풀궶트라이핑 된 파일 시스템을 만드는데 사용됩니다. 일반적으로, 루트나 /var/tmp (와)과 같이 작은 파티션, 혹은 /usr (와)과 같은 본질적으로 읽을 보고의 파티션을 스트라이핑 해도 시간의 쓸데없게 밖에 되지 않습니다. 정말로 입출력 성능을 필요로 하는 파티션만을 스트라이핑 해야 합니다. 전형적으로는 /var (이)나 /home 혹은 데이타베이스나 Web 페이지를 보관 유지하는 커스텀 파티션입니다. 적절한 스트라이프 사이즈를 선택하는 일도 중요합니다. 파일 시스템은 메타데이타를 2 의 누승의 경계에서 격납하는 경향에 있어, 대체로는 시크를 늘리는 것이 아니라 줄이고 싶을 것입니다. 이것은, 1152 섹터라고 한 것 같은, 시퀀셜인 I/O 가 양쪽 모두의 디스크를 시크 하지 않게, 한편 메타데이타가 단일의 디스크에 집중하는 것이 아니라 양쪽 모두에 분산하는 것 같은, 중심을 빗나간 (off-centered) 큰 스트라이프 사이즈로 하고 싶은, 이라고 하는 것을 의미합니다. 정말로 성능이 필요하면, FreeBSD 하지만 서포트하는 진짜의 하드웨어 RAID 콘트롤러를 사용하는 것을 권합니다.

sysctl 에 의한 튜닝
sysctl(8) 변수는, 실행시에, 시스템의 동작의 모니터 및 제어를 가능으로 합니다. sysctl 에는, 단지 시스템의 동작을 보고하는 것도 있습니다만, 시스템의 동작을 변경하는 것도 있습니다. 부트시에 rc.conf(5) (을)를 사용해 설정 가능한 것도 있습니다만, 대부분은 sysctl.conf(5) 그리고 설정 가능합니다. 시스템에는 수백의 sysctl(8) 변수가 존재합니다. 그 안에는, 튜닝의 후보와 같이 보입니다만 사실은 그렇지 않은 것도 많이 포함됩니다. 이 문서에서는 시스템에 가장 큰 영향을 주는 것만을 취급합니다.

kern.ipc.shm_use_phys sysctl 는, 디폴트가 0 (오프)이며, 0 (오프) 또는 1 (온)에 세트 할 수가 있습니다. 이 파라미터를 1 에 세트 하면(자), 모든 System V 공유 메모리세그먼트가 페이징 불가의 물리 메모리에 MAP 됩니다. 이것은, (A) 대량 (수백)의 프로세스간에 소량의 공유 메모리를 매핑 하고 있는지, (B) 임의개의 프로세스간에 대량의 공유 메모리를 매핑 하고 있는, 의 몇개의 경우에 효과가 있습니다. 이 기능은, 공유 메모리를 스왑 불가로 하는 것으로, 공유 메모리를 코어에 연결시킬 때에 생기는, 커널에 있어서의 내부의 메모리 메니지먼트에 의한 페이지 추적 오버헤드를 꽤 줄입니다.

vfs.vmiodirenable sysctl 는, 디폴트는 0 (오프)이며 (그러나 가까운 시일내에 디폴트가 1 에 되겠지요), 0 (오프) 또는 1 (온)에 세트 할 수가 있습니다. 이 파라미터는, 디렉토리가 시스템에 의해 어떻게 캐쉬되는지를 제어합니다. 대부분의 디렉토리는 작고, 파일 시스템에 대해 단일 fragment (전형적으로는 1K) (이어)여, 버퍼 캐쉬에서는 한층 더 작아지고 있습니다 (전형적으로는 512 바이트). 그러나, 디폴트 모드로 동작하고 있을 때는, 대량의 메모리를 탑재하고 있어도 버퍼 캐쉬는 고정수의 디렉토리 밖에 캐쉬하지 않습니다. 이 sysctl 를 온으로 하면(자), 버퍼 캐쉬가 VM 페이지 캐쉬를, 디렉토리를 캐쉬하기 위해서 사용하는 것을 가능하게 합니다. 여기에 따른 이점은, 모든 메모리가 디렉토리를 캐쉬하는데 사용할 수 있게 된다고 하는 것입니다. 결점은, 캐쉬에 사용되는 최소의 메모리의 크기가 512 바이트는 아니고 물리 페이지 사이즈 (대체로는 4K)가 되는 것입니다. 메모리에 제약이 있는 시스템에서는, 이 옵션을 오프로 하는 것을 추천 합니다. 한편, 온으로 하면(자), 다수의 파일을 조작하는 서비스의 성능이 향상합니다. 그러한 서비스에는, web 캐쉬나, 대규모 메일 시스템, 뉴즈시스템등이 포함됩니다. 이 옵션은 일반적으로 메모리를 소비합니다만, 성능을 삭감할 것은 없습니다. 다만 실험해 조사해 보아야 하는이지요.

vfs.write_behind sysctl 는, 디폴트로 1 (온)입니다. 이것에 의해, 파일 시스템으로부터 미디어에의 기입이, 클러스터분이 모였을 때에 발행되게 됩니다. 그러한 상황은, 전형적으로는, 큰 순차 파일에 기입하고 있을 때에 일어납니다. 이것은, I/O 퍼포먼스에 기여하지 않을 것이다 경우에, 더티인 버퍼로 버퍼 캐쉬가 포화하는 것을 피한다고 한다 아이디어입니다. 그렇지만, 이것에 의해 프로세스가 멈출지도 모르기 때문에, 상황에 따라서는 이 기능을 자르고 싶으면 바랄지도 모릅니다.

vfs.hirunningspace sysctl 는, 임의의 시점에 있어 시스템 전체로, 디스크 콘트롤러의 큐에 넣어 미완료 상태로 해 좋은, 기입 I/O 의 양을 결정합니다. 통상, 기본값로 충분합니다만, 디스크를 많이 가지는 머신에서는 4, 5 메가바이트로 늘리고 싶어질지도 모릅니다. 값을 너무 크게 한다 (버퍼 캐쉬의 기입의 반응을 일으키는 최소의 물리량을 넘어)와 클러스터링의 효과가 극단적으로 나빠진다 가능성이 있을테니 주의해 주세요. 이 값을 착상으로 크게 해 안됩니다! 또 기입의 큐치를 크게 하면(자), 동시에 발생했다 읽기이고가 기다리게 될지도 모릅니다.

그 밖에도 버퍼 캐쉬와 VM 페이지 캐쉬에 관련한, 여러가지 sysctl 가 존재합니다. 이것들을 변경하는 것은 추천 되지 않습니다. FreeBSD 4.3 에 대해 말하면, VM 시스템은 자기 자신의 튜닝에 관해서 몹시 좋다 일을 하고 있습니다.

net.inet.tcp.sendspace sysctl 와 net.inet.tcp.recvspace sysctl 는, 네트워크에 관련하는 어플리케이션을 가동하고 있는 경우는 특히 중요합니다. 이것은, TCP connection의 송신 및 수신 버퍼 area의 크기를 조절합니다. 디폴트에서는, 송신 버퍼는 32K 로, 수신 버퍼는 64K 입니다. 이 디폴트를 늘리는 것으로 각 connection에 대해 카네르메모리가 한층 더 소비됩니다만, 대역폭의 이용율이 개선하는 일이 있습니다. 동시에 수백이라든지 수천의 connection를 취급하고 있는 경우, 이 디폴트를 늘리는 것은 추천 되지 않습니다. 실속해 버린 connection가 축적하는 것으로, 시스템이 메모리를 곧바로 다 써 버려 버리기 때문입니다. 그러나, 적은 수의 connection에 대해 넓은 대역폭이 필요하면, 특히 Gigabit Ethernet의 경우, 이 디폴트를 큰폭으로 늘린다 일이 생깁니다. 입력 데이터와 출력 데이터의 버퍼를 개별적으로 조정할 수가 있습니다. 예를 들어, 주로 web 서비스를 하고 있는 머신이라면 recvspace 를 줄이는 것으로, 그만큼 대량으로 카네르메모리를 소비하지 않고 sendspace 를 늘릴 수가 있습니다. 경로표 ( route(8) (을)를 참조 )에 대해서는, 경로에 특화한 송수신 버퍼를 도입하는 것이 할 수 있기로 주의해 주세요.

부가적인 관리툴로서 파이어 월(fire wall) 룰에 대해 파이프 (pipe)를 사용하는 것으로 ( ipfw(8) (을)를 참조), 특정의 IP 블록이나 포트에 간다, 혹은 거기로부터 오는 대역폭을 제한할 수가 있습니다. 예를 들면 T1 회선을 가지고 있는 경우, web 트래픽은 회선의 70% 에 제한해, 나머지를 메일과 인터랙티브인 용도에 사용하고 싶다고 생각하겠지요. 통상 높은 부하의 web 서버는, 네트워크 회선이 다 사용해지고 있어도, 다른 서비스에 큰 지연을 주는 것은 없습니다만, 제한을 걸치는 것은 사물을 원활히 해 장기적인 안정으로 연결됩니다. 또, 많은 사람이, 대역 초과에 의한 과금을 하시지 않게 의도적인 대역 제한을 걸치고 있습니다.

net.inet.tcp.rfc1323 sysctl 로 제어 가능한 TCP 프로토콜의 윈도우 슬캘링 확장을 양쪽 모두의 호스트가 서포트하지 않는 한, TCP 의 송신 혹은 수신 버퍼 사이즈를 65535 를 넘어 지정해도 거의 성능의 개선은 없습니다. 어떤 종류의 네트워크 링크로부터 좋은 성능을 꺼내기 위해서(때문에), 이러한 확장을 유효하게 해, TCP 버퍼 사이즈를 65536 보다 크게 설정해야 합니다. 특히, 기가비트 WAN 링크나, 고지연시간의 위성 링크가 대상이 됩니다. RFC1323 서포트는, 디폴트로 온이 되어 있습니다.

net.inet.tcp.always_keepalive sysctl 는, TCP 실장이, connection상에 단속적으로 “keepalives” (을)를 배송하는 것으로 죽어 버린 TCP connection의 검출을 시도할까 제발을 결정합니다. 디폴트로, 이것은 모든 어플리케이션에 대해 허가되고 있습니다. 이 sysctl 를 0 으로 설정하면(자), 특히 keepalives 를 요구했다 어플리케이션만이 검출 기능을 이용할 수 있습니다. 대체로의 환경에 있어, 죽어 버린 TCP connection를 실효로 하는 것으로, TCP keepalives 는 시스템 상태의 관리를 개선합니다. 특히 다이얼 업의 유저에게 서비스를 제공하고 있는 시스템에서는 효과가 있습니다. 왜냐하면 유저가 네트워크와의 connection를 자르기 전에 언제나 개개의 TCP connection를 종료한다고는 할 수 없기 때문입니다. 그렇지만, 어떤 종류의 환경에서는, 일시적인 네트워크의 정지가 잘못해 세션의 죽음이라고 판단될지도 모릅니다. 결과적으로 예기치 않은 TCP connection의 종료가 됩니다. 그 같은 환경에서는, sysctl 를 0 으로 설정하는 것으로, TCP 의 세션 절단의 발생을 줄일 수 있을지도 모릅니다.

net.inet.tcp.delayed_ack TCP 기능은 크게 오해 받고 있습니다. 역사적으로는, 이 기능은, 전송 된 데이터에 대한 확인 응답을, 응답과 함께 돌려줄 수 있도록(듯이) 하기 위해서 디자인되었습니다. 예를 들면, 리모트 쉘상에서 키 입력하고 있을 때, 당신이 송신한 캐릭터에의 확인 응답은, 캐릭터의 에코를 나타내는 데이터와 함께 돌려주어집니다. 지연 확인 응답을 오프로 하면(자), 리모트 서비스가 꼭 받은 데이터를 에코 할 기회를 얻기 전에, 확인 응답이 그 만큼을 포함한 패킷으로 보내져 버릴지도 모릅니다. 이 같은 생각이 모든 대화적 프로토콜 (예 SMTP, WWW, POP3)에 들어맞아, 네트워크의 한쪽을 흐르고 있는 소패킷을 줄일 수 있습니다. FreeBSD 의 지연 확인 응답의 실장도, TCP 프로토콜의 규칙에 따르고 있습니다. 즉, 표준의 100ms 의 타임 아웃이 경과하지 않아도, 2 패킷에 1 회는 확인 응답을 실시합니다. 통상, 지연 확인 응답이 실시하는 최악는, connection의 파괴를 조금 늦추는 것, 슬로우 스타트 TCP connection의 첫 시작을 조금 늦추는 것입니다. 확실한 (일)것은 모릅니다만, SAMBA 나 SQUID 라고 하는 package 에 관련하는 FAQ 가 지연 확인 응답을 오프로 하도록 권하고 있는 것은, 슬로우 스타트의 문제에 언급하고 있겠지요. FreeBSD 에서는, 슬로우 스타트 플라이트 사이즈를 net.inet.tcp.slowstart_flightsize sysctl 로 늘리는 것이, 지연 확인 응답을 오프로 하는 것보다, 이익이 있겠지요.

net.inet.tcp.inflight_enable sysctl 는, 모든 TCP connection에 대해, 밴드폭과 지연의 적에 의한 제한을 적용합니다. 시스템은, 각 connection에 대해서 밴드폭과 지연의 적을 계산해, 네트워크에 큐 되는 데이터량을, 최적인 throughput를 확보하는데 필요한 양으로 한정하려고 합니다. 이 기능이 유용한 것은, 모뎀이나 기가빗트이사나 고속 WAN 링크 (라고 하는 밴드폭과 지연의 적이 큰 네트워크) 경유로 데이터를 제공하고 있는 경우이며, 특히 유용한 것은, 윈도우 슬캘링을 병용 하고 있는 경우나 큰 송신 윈도우를 설정했을 경우입니다. 본옵션을 유효하게 하는 경우, net.inet.tcp.inflight_debug (을)를 0 (디버그 무효)으로 설정하는 것을 잊지 않고. 열매 운용에서는, net.inet.tcp.inflight_min (을)를 적어도 6144 로 설정하면(자) 유용하겠지요. 그렇지만, 최저치를 크게 설정하면(자), 링크에 따라서는 밴드폭 제한을 무효로 하는 결과가 될 수 있는 것에 주의해 주세요. 본한정 기능은, 중간 라우터나 스윗치의 패킷 큐에 축적되는 데이터량을 줄여, 로컬 호스트의 인터페이스 큐에 축적되는 데이터량도 줄입니다. 큐 되는 패킷수가 적다고 대화적 connection, 특히 저속 모뎀 경유의 것은, 짧은 왕복 시간에서의 동작이 가능하게 됩니다. 그렇지만, 이 기능은 데이터 송신 (업 로드 / 서비스측)에게만 영향을 주는 것에 주의해 주세요. 데이터 수신 (다운로드)에는 영향을 주지 않습니다.

net.inet.ip.portrange. * sysctls 는, 자동적으로 TCP 나 UDP 소켓에 결합되는 포트 번호의 범위를 제어합니다. 3 종류의 범위가 있습니다. 즉, 하위의 범위, 디폴트의 범위, 고위의 범위이며, IP_PORTRANGE setsockopt() 호출로 선택 가능합니다. 대부분의 네트워크 프로그램이 사용하는 것은 디폴트의 범위이며, net.inet.ip.portrange.first (와)과 net.inet.ip.portrange.last 그리고 제어됩니다. 각각 1024 로 5000 이 디폴트입니다. 범위가 한정된 포트 범위는 밖으로 향한 connection에 사용되어 어느 조건하에서는 시스템이 포트를 사용해 다해 버리는 경우가 있습니다. 이것은, 고부하의 웹 프록시를 실행하고 있는 경우에, 자주(잘) 발생합니다. 통상의 웹 서버등의 주로 내향 connection를 취급하는 서버나, 메일 릴레이등의 밖으로 향한 connection가 한정되어 있는 서버를 실행하고 있는 경우, 이것은 문제는 되지 않습니다. 포트를 다 써 버려 버리는 경우, 적당히 net.inet.ip.portrange.last (을)를 늘려 보세요. 10000, 20000, 30000 이라고 하는 값은 괜찮겠지요. 포트의 범위를 바꿀 때는, 파이어 월(fire wall)의 영향도 고려에 넣어야 합니다. 파이어 월(fire wall)에 따라서는, 넓은 범위의 포트 (통상은 하위의 포토) (을)를 가림해, 시스템이 고위의 포트를 밖으로 향한 connection에 사용하는 것을 기대합니다. 이 때문에, net.inet.ip.portrange.first (을)를 저하시키는 것은 추천할 수 없습니다.

kern.ipc.somaxconn sysctl 는, 새로운 TCP connection를 받아들이기 위한 listen 큐의 사이즈를 제한합니다. 고부하의 web 서버 환경에서는, 기본값의 128 은 새로운 connection를 여유를 가지고 취급하기에는 너무 낮습니다. 그러한 환경에서는, 이 값을 1024 이상으로 늘리는 것이 추천 됩니다. 서비스 demon (예를 들면 sendmail(8) (이)나 apache)는 자기 자신의 listen 큐의 사이즈를 제한하고 있을지도 모릅니다만, 설정 파일로 큐의 사이즈를 늘리는 지시문을 가지게 되겠지요. listen 큐를 크게 하는 것은, 서비스 거부 공격을 막는데도 도움이 됩니다.

kern.maxfiles sysctl 는, 시스템이 얼마나의 수의 파일을 오픈할 수 있을까를 결정합니다. 디폴트는 전형적으로는 수천입니다만, 데이타베이스나 기술자를 대량으로 사용하는 demon를 가동하고 있는 경우는 10000 이나 20000 으로 끌어올릴 필요 (이)가 있을지도 모릅니다. 읽기 전용의 kern.openfiles sysctl 를 검사하는 것으로, 시스템상에서 열리고 있는 파일수를 판정 가능합니다.

vm.swap_idle_enabled sysctl 는, 다수의 유저가 시스템에 출입해 대량의 아이돌 프로세스가 어느 큰 multiuser 시스템으로 편리합니다. 그러한 시스템에서는, 후리메모리의 예약에 대해, 계속해 중대한 부담을 주는 경향에 있습니다. 이것을 온으로 해 vm.swap_idle_threshold1 sysctl 와 vm.swap_idle_threshold2 sysctl 로 스왚 아웃 히스테리시스 (아이돌의 초수)를 조정하는 것으로 아이돌 프로세스에게 줄 수 있고 있는 페이지의 우선도를 통상의 페이지 아웃 알고리즘보다 신속하게 내릴 수가 있습니다. 이것은 페이지 아웃 demon를 돕습니다. 필요가 없는 한, 이 옵션은 온으로 하지 말아 주세요. 이것에 의해 일어나는 트레이드 오프는, 본질적으로, 스왑과 디스크 대역폭을 보다 많이 소비해 메모리의 프리페이징을 보다 빠른 동안에 실시하는 것이기 때문입니다. 작은 시스템에서는 이 옵션은 유해가 되겠지만, 벌써 어느 정도 페이징이 발생하고 있는 큰 시스템에서는, 이 옵션에 의해, 전체의 프로세스가 보다 용이하게 메모리에 들어가거나 나오거나 하도록 할 수 있겠지요.

로더의 츄나불
시스템의 동작의 일부는, 그것을 위한 메모리 할당을 부트 처리의 초기에 실시할 필요가 있기 위해서(때문에), 실행시에는 조정 불가능합니다. 로더의 츄나불을 변경하려면 , 이러한 값을 loader.conf(5) (으)로 설정해, 시스템을 리부트할 필요가 있습니다.

kern.maxusers (은)는, 정적인 시스템 테이블의 크기를 제어합니다. 이것에는, 오픈 파일의 최대수, 네트워크메모리 자원의 크기등이 포함됩니다. FreeBSD 4.5 의 시점에서는, kern.maxusers (은)는, 부트시에, 시스템으로 이용 가능한 메모리량에 응해, 크기가 자동적으로 결정됩니다. 또, 실행시에, 독해 전용의 kern.maxusers sysctl 치를 봐 결정하는 일도 가능합니다. 사이트에 따라서는, kern.maxusers (을)를 크게 하거나 작게 하거나 할 필요가 있어, 이것은 로다츄나불로 설정 가능합니다. 64, 128, 256 은, 이상한 값이 아닙니다. 방대한 파일 기술자가 필요해서 않은 한, 256 보다 크게 하는 것은 권유받지 않습니다. kern.maxusers 에 의해 기본값이 결정되는 많은 츄나불치는, 본문서의 다른 장소에 기술한 방법으로, 개개에 부트시 또는 실행시에 덧쓰기 가능합니다. FreeBSD 4.4 보다 낡은 시스템에서는, 커널의 config(8) 옵션의 maxusers (을)를 설정할 필요가 있습니다.

kern.ipc.nmbclusters (을)를 조정하는 것으로, 시스템이 할당하려 하고 있다 네트워크 mbuf 의 수를 늘릴 수가 있습니다. 각각의 클러스터는 약 2K 의 메모리에 상당하므로, 1024 는 2M 의 카네르메모리를 네트워크버퍼에 예약하는 것을 나타냅니다. 간단한 계산으로 얼마나 필요한가를 알 수 있습니다. web 서버가 동시에 최대 1000 개의 connection를 취급해, 각 connection가 16K 의 수신 버퍼와 16K 의 송신 버퍼를 소비하는 경우, 약 32MB 에 상당하는 네트워크버퍼를 취급할 필요가 있습니다. 경험으로부터 얻은 방법에 의하면, 2 배가 되면 좋다고 여겨지고 있습니다. 즉 32MBx2 = 64MB/2K = 32768 입니다. 따라서, 이 경우는 kern.ipc.nmbclusters (을)를 32768 으로 설정합니다. 안만한 양의 메모리가 탑재된 머신에서는 1024 에서 4096, 한층 더 대량의 메모리가 탑재되고 있다면 4096 에서 32768 의 값을 추천 합니다. 결코 큰 값을 지정해야 하지는 않습니다. 부트시에 크래쉬를 일으킬 가능성이 있습니다. netstat(1) 에 -m 옵션을 주는 것으로, 네트워크 클러스터의 사용 상황을 알 수 있습니다. 낡다 FreeBSD 그럼 이 츄나불을 가지지 않으므로, 대신에 커널의 config(8) 옵션의 NMBCLUSTERS (을)를 설정할 필요가 있습니다.

더욱 더 많은 프로그램이 sendfile(2) 시스템 콜을 사용해 네트워크를 통해서 파일을 전송 하고 있습니다. kern.ipc.nsfbufs sysctl 는 sendfile(2) 의 실행시에 파일 시스템 버퍼를 얼마나의 수만큼 사용할 수 있는지를 제어합니다. 통상 이 파라미터는 kern.maxusers 에 비례하고 있으므로, 극단적인 경우를 제외해 이 파라미터에 손을 댈 필요는 없습니다.

커널 구성에 있어서의 튜닝
대규모 시스템에서는, 몇개의 커널 옵션을 조작하지 않으면 안 될지도 모릅니다. 이러한 옵션을 변경하는 경우, 당신은 소스로부터 새로운 커널을 컴파일 할 수 없으면 안됩니다. config(8) 메뉴얼 페이지나 핸드북이 좋은 입문이 되겠지요. 당신만의 custom car 네루를 만들 때 일반적으로 최초로 하는 것은, 사용하지 않는 드라이버나 서비스를 모두 깎는 것입니다. INET6 (이)나 사용하지 않는 드라이버를 삭제하는 것으로, 커널의 사이즈를 때에 1 메가바이트 이상 줄일 수가 있어 어플리케이션에 한층 더 메모리를 줄 수가 있습니다.

SCSI_DELAY (와)과 IDE_DELAY (은)는, 시스템의 기동 시간을 줄이기 위해서(때문에) 사용할 수가 있습니다. 이 기본값은 꽤 크고, 부트 처리 중(안)에서 15 초 이상을 차지하겠지요. SCSI_DELAY (을)를 5 초로 줄여도 대체로는 잘 움직입니다 (특히 최근의 드라이브에서는). IDE_DELAY (을)를 줄여도 잘됩니다만, 조금 신중하게 될 필요가 있습니다.

*_CPU 옵션의 상당수는 comment out 할 수 있습니다. 그 커널을 Pentium 클래스의 CPU 만으로 움직인다면, I386_CPU (와)과 I486_CPU (은)는 삭제할 수가 있습니다. 다만, I586_CPU (은)는, CPU 가 Pentium II 이상으로서 인식되는 것을 확인하고 나서 삭제해 주세요. Pentium 나 486 으로서조차 인식되는 클론이 존재해, 그 경우는 이러한 옵션이 없으면 기동할 수가 없습니다. 만약 움직이면(자) 대단한 일입니다 ! operating system는, MMU 나 태스크 바꾸어 타임 베이스, 디바이스 조작에 이르는, 보다 고도의 기능을 보다 이용할 수가 있게 됩니다. 더해보다 고도의 CPU 는, 커널이 커넬 자신을 메모리에 MAP 한다 4MB 의 MMU 페이지를 서포트합니다. 이것은 높은 시스템 콜 부하의 아래에서의 효율을 올립니다.

IDE 라이트 캐쉬
FreeBSD 4.3 그럼 IDE 의 라이트 캐쉬가 오프가 되었습니다. 이것은 IDE 디스크에의 기입해 대역폭을 줄여 버리게 됩니다만, 하드 드라이브 vender에 기인하는 데이터의 일관성에 관한 중대한 문제를 위해서(때문에), 필요한 일이라고 생각되었습니다. 기본적으로는, 기입 완료 시기에 대해 IDE 드라이브가 거짓말한다고 하는 문제입니다. IDE 라이트 캐쉬가 온이라고, IDE 하드 드라이브는 데이터를 차례로 써 넣지 않을 뿐만 아니라, 디스크의 부하가 높을 때에는 몇개의 블록의 기입을 무기한으로 연기해 버립니다. 크래쉬나 전원 고장의 경우, 파일 시스템의 중대한 파괴를 가져옵니다. 따라서 우리는 디폴트를 안전 측에 변경했습니다. 유감스럽지만, 이것은 대단한 성능의 저하를 가져와, 우리는 포기해 이 릴리스 후에 온에 되돌렸습니다. hw.ata.wc sysctl 변수를 봐, 디폴트를 체크해 보아야 하는입니다. 만약 IDE 라이트 캐쉬가 오프가 되어 있으면(자), hw.ata.wc 로다츄나불을 1 으로 설정하는 것으로 온에 되돌릴 수가 있습니다. ATA 드라이버 시스템의 튜닝에 관한 한층 더 정보는, ata(4) (을)를 참조해 주세요.

IDE 하드 드라이브의 실험적인 신기능으로서 hw.ata.tags (으)로 불리는 것이 있어 (이것도 부트 로더로 설정합니다), 라이트 캐쉬를 안전하게 온으로 할 수가 있습니다. 이것은 SCSI 의 줄다리기 기능을 IDE 드라이브에 반입한 것입니다. 이것을 쓰고 있는 시점에서는, IBM DPLA 와 DTLA 드라이브만이 이 기능을 서포트하고 있습니다. 경고! 이러한 드라이브는 품질관리에 문제 (이)가 있는 것 같아서, 나는 현시점에서는 이러한 제품을 사는 것은 추천하지 않습니다. 성능이 필요하면 SCSI 를 사용합시다.

CPU, 메모리, 디스크, 네트워크
부하가 오르면(자) 시스템의 어느 부분이 보틀 넥이 되기 시작할까 에 의해, 튜닝의 종류가 달라집니다. CPU 를 다 써 버리고 있는 (아이돌 시간이 항상 0%)라면, CPU 를 업그레이드 하거나 SMP 메인보드 (CPU 를 복수로 한다)에 이행 하거나 혹은 부하의 원인이 되고 있는 프로그램을 다시 봐 최적화한다 일을 생각할 필요가 있겠지요. 스왑에 대해서 대량의 페이징이 있다면 메모리를 좀 더 늘릴 필요가 있겠지요. 디스크 성능이 포화하고 있는 경우, CPU 아이돌 시간은 높고, 전반적으로 디스크가 포화 상태가 되어 있습니다. systat(1) 그리고 이것들을 모니터 할 수가 있습니다. 디스크 성능의 포화를 해결하려면 여러가지 방법이 있습니다: 캐쉬를 위한 메모리를 늘리는, 디스크를 미러링 하는, 복수의 머신에 조작을 분산시키는 등입니다. 디스크 성능이 문제로, IDE 드라이브를 사용하고 있는 경우, SCSI 로 전환하는 것으로 대단히 좋아집니다. 생의 시퀀셜인 대역폭에 대해서는, 최근의 IDE 드라이브는 SCSI 의 것에 필적하고 있습니다만, 조사하면(자) 대체로 SCSI 드라이브가 이기고 있습니다.

마지막으로, 네트워크 성능을 다 써 버리고 있을지도 모릅니다. 네트워크 성능을 개선하기 위해서 최초로 확인 해야 할것은, 허브는 아니고 스윗치를 사용하고 있는지, 라고 하는 것입니다. 특히 최근에는 스윗치는 싸지고 있습니다. 허브가 고부하가 되면(자), collision 백 오프를 위해서(때문에) 심각한 문제가 발생합니다. 또, 1 대의 호스트에 문제가 있으면(자), LAN 전체의 성능을 큰폭으로 저하시킵니다. 다음에, 가능한 한 네트워크 경로를 최적화하는 것입니다. 예를 들면 firewall(7) 그리고 설명한 내부 호스트를 지키는 파이어 월(fire wall)에서는, 외부로부터 보이는 호스트는 파이어 월(fire wall)를 통하지 않는 위상기하학입니다. 필요에 따라서 10BaseT 는 아니고 100Base-T 를, 혹은 100BaseT 는 아니고 1000BaseT 를 사용합시다. 최대의 보틀 넥은 WAN 회선입니다 (모뎀, T1, DSL 등 ). 회선을 증강할 수 없는 것이면, dummynet(4) 기능을 사용해 피크 삭감이나 그 외의 트라픽크시이핑을 행동과부하의 서비스 (web 서비스등 )가 다른 서비스 (전자 메일등 ) 에 영향을 주는 것을 막아 주세요. 역도 또 같습니다. 이것은, 가정환경에 대해, 외부에 공개하고 있는 서비스 (web 서비스나 전자 메일)보다 인터랙티브인 트래픽 (브라우저나 ssh(1) 로그인)을 우선하기 위해서 사용할 수가 있겠지요.

관련 항목
netstat(1), systat(1), ata(4), dummynet(4), login.conf(5), rc.conf(5), sysctl.conf(5), firewall(7), hier(7), ports(7), boot(8), ccdconfig(8), config(8), disklabel(8), fsck(8), ifconfig(8), ipfw(8), loader(8), mount(8), newfs(8), route(8), sysctl(8), sysinstall(8), tunefs(8), vinum(8)

역사
tuning 메뉴얼 페이지는, 원래 Matthew Dillon 에 의해 쓰여졌습니다. 최초로 등장한 것은 FreeBSD 4.3 그리고, 2001 년 5 월의 일입니다.