몇 개월 후 극단적 인 ZFS 속도 저하


8

메일, DNS, 웹, 데이터베이스 및 기타 여러 서비스를 제공하는 범용 서버가 있습니다.

3.40GHz, 16GB ECC RAM의 Xeon E3-1275가 있습니다. ZFS-on-Linux 0.6.5.3과 함께 Linux 커널 4.2.3 실행

디스크 레이아웃은 Seagate ST32000641AS 2TB 드라이브 2 개 및 Samsung 840 Pro 256GB SSD 1 개입니다.

RAID-1 미러에 2 개의 HD가 있고 SSD는 캐시 및 로그 장치 역할을하며 모두 ZFS에서 관리됩니다.

처음 시스템을 설정했을 때 놀라 울 정도로 빨랐습니다. 실제 벤치 마크가없고 빠릅니다.

이제는 특히 모든 maildir을 보유하는 파일 시스템에서 속도가 매우 느려집니다. 야간 백업을 수행하는 데 46GB의 메일 만 있으면 90 분 이상 걸립니다. 때로는 백업으로 인해 시스템이 최대 6 시간 동안 거의 응답하지 않는 과도한로드가 발생합니다.

이러한 속도가 느려지 zpool iostat zrootzroot동안 (풀 이름이 ) 실행 되었으며 초당 100-200kbytes의 쓰기가 이루어졌습니다. 명백한 IO 오류가 없으며 디스크가 특히 열심히 작동하지 않는 것 같지만 읽기 속도가 거의 느립니다.

이상한 점은 FreeBSD를 실행하는 SSD는 없지만 비슷한 사양의 하드웨어를 사용하여 다른 컴퓨터에서 똑같은 경험을했다는 것입니다. 몇 달 동안 잘 작동했지만 같은 방식으로 느려졌습니다.

내 의심은 이것입니다 : 나는 zfs-auto-snapshot을 사용합니다. 각 파일 시스템의 롤링 스냅 샷을 만들 수 있습니다. 15 분, 시간별, 일별 및 월간 스냅 샷을 생성하고 가장 오래된 것을 삭제하여 각 주변에 일정한 수의 스냅 샷을 유지합니다. 이는 시간이 지남에 따라 각 파일 시스템에서 수천 개의 스냅 샷이 생성 및 파괴되었음을 의미합니다. 누적 효과로 생각할 수있는 유일한 진행중인 파일 시스템 수준 작업입니다. 모든 스냅 샷을 삭제하려고 시도했지만 (프로세스를 계속 실행하고 새 스냅 샷을 작성) 변경 사항이 없습니다.

지속적으로 스냅 샷을 생성 및 삭제하는 데 문제가 있습니까? 나는 그것들을 매우 귀중한 도구로 사용하고 있으며, 디스크 공간을 제외하고는 거의 제로 비용이라고 믿게되었습니다.

이 문제를 일으킬 수있는 다른 것이 있습니까?

편집 : 명령 출력

출력 zpool list:

NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot  1.81T   282G  1.54T         -    22%    15%  1.00x  ONLINE  -

출력 zfs list:

NAME             USED  AVAIL  REFER  MOUNTPOINT
zroot            282G  1.48T  3.55G  /
zroot/abs       18.4M  1.48T  18.4M  /var/abs
zroot/bkup      6.33G  1.48T  1.07G  /bkup
zroot/home       126G  1.48T   121G  /home
zroot/incoming  43.1G  1.48T  38.4G  /incoming
zroot/mail      49.1G  1.48T  45.3G  /mail
zroot/mailman   2.01G  1.48T  1.66G  /var/lib/mailman
zroot/moin       180M  1.48T   113M  /usr/share/moin
zroot/mysql     21.7G  1.48T  16.1G  /var/lib/mysql
zroot/postgres  9.11G  1.48T  1.06G  /var/lib/postgres
zroot/site       126M  1.48T   125M  /site
zroot/var       17.6G  1.48T  2.97G  legacy

이것은 일반적으로 매우 바쁜 시스템이 아닙니다. 아래 그래프의 피크는 야간 백업입니다.

IO 통계

나는 감속하는 동안 시스템을 잡을 수있었습니다 (오늘 아침 8 시부 터 시작). 일부 작업은 반응이 좋지만 현재로드 평균은 145이며 zpool list중단됩니다. 그래프:

/ dev / sdb 대기 시간


제시해주십시오 zpool listzfs list.
ewwhite

수영장이 거의 80 % 찼습니까? 문제가 발생할 수 있습니다.
Ryan Babchishin

아뇨 .. 리눅스에서 ZFS 루트입니다. 흠 ... 당신은 할 적이 어떤 튜닝을? 또한 조각화가 발생할 수 있습니다. ZoL 버전은 무엇입니까? 전혀 업데이트 했습니까?
ewwhite

내용을 올바르게 읽으면 zpool은 버전 28이고 zfs는 버전 5입니다. ZoL은 최신 0.6.5.3입니다.
Kaolin Fire

또한 SSD가 로그로 많이 사용되면 실패 할 수 있다고 제안되었지만 SMART는 잘하고 있다고 말합니다. ... 오류를 Reallocated_Sector_Ct 0, 생값 402 Wear_Leveling_Count 없다 (그리고 값은 88이다)
카올린 화재를

답변:


1

arc_meta_used 및 arc_meta_limit를보십시오. 작은 파일이 많으면 메타 데이터 캐시를 램에 채워 디스크에서 파일 정보를 찾아야하므로 크롤링 속도가 느려질 수 있습니다.

Linux 에서이 작업을 수행하는 방법을 잘 모르겠습니다. FreeBSD에 대한 경험이 있습니다.


재미있는 — 감사합니다! 참조를 위해 github.com/zfsonlinux/zfs/issues/1261 추가 혼돈 루트 : ~ # cat / proc / spl / kstat / zfs / arcstats | grep arc_meta_used arc_meta_used 4 5895985776 혼돈 루트 : ~ # cat / proc / spl / kstat / zfs / arcstats | grep arc_meta_limit arc_meta_limit 4 6301327872
카올린 화재

디스크 IO 속도를 살펴보면 실제로 실제 디스크 활동이 많지 않은 것 같습니다.
오징어
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.