RAID-10에 두 개의 Intel DC S3610 SSD가 있는 Debian jessie 서버가 있습니다. IO로 인해 상당히 바빠서 지난 몇 주 동안 IOPS를 그래프로 작성했습니다.
보시다시피, 금요일 자정(UTC)에 갑자기 중지되고 읽기 작업이 거의 아무것도 없는 것처럼 보일 때까지 대부분 약 1,000회의 평균 읽기 작업을 최대 5,500회까지 성공적으로 수행했습니다.
실제로 서버가 여전히 제대로 작동하고 있기 때문에 이 사실을 소급해서 알아차린 것뿐입니다. 즉, 깨지는 것은 모니터링이지 설정이 할 수 있는 IOPS의 양이 아니라고 생각합니다. 실제 IOPS가 표시된 수준으로 떨어졌다면 다른 모든 것이 눈에 띄게 중단될 것이기 때문에 알 수 있습니다.
추가 조사에서 킬로바이트 단위의 읽기/쓰기 그래프도 같은 지점에서 깨졌습니다. 요청 대기 시간 그래프는 괜찮습니다.
여기에서 사용되는 특정 그래프 솔루션(선인장 및 SNMP)을 배제하기 위해 다음을 살펴보았습니다.iostat. 출력은 그래프에 표시되는 것과 일치합니다.
내가 아는 한iostat정보를 얻습니다./proc/diskstats. 에 따르면https://www.kernel.org/doc/Documentation/iostats.txt메이저, 마이너, 장치 이름과 일련의 필드가 있으며 첫 번째 필드는 완료된 읽기 수입니다. 그래서:
$ for i in {1..10}; do awk '/sda / { print $4 }' /proc/diskstats; sleep 1; done
3752035479
3752035484
3752035484
3752035486
3752035486
3752035519
3752035594
3752035631
3752036016
3752036374
10초 동안 그렇게 적은 수의 읽기가 완료되었다는 것은 믿을 수 없습니다.
하지만 만약/proc/diskstats나에게 거짓말을 하고 있다면 문제는 무엇이며 어떻게 해결할 수 있습니까?
또한 흥미로운 점은 무엇이 바뀌든 정확히 자정에 바뀌었다는 사실인데, 이는 오히려 우연의 일치입니다.
서버에는 꽤 많은 블록 장치가 있습니다. 그 중 187개는 LVM LV이고, 또 다른 18개는 일반적인 파티션 및 md 장치입니다.
나는 정기적으로 더 많은 LV를 추가해왔기 때문에 목요일에 일종의 제한에 도달했을 가능성이 있습니다. 하지만 자정 근처에는 아무 것도 추가하지 않았으므로 잘못된 것이 무엇이든 자정에 그렇게 되었다는 것은 여전히 이상합니다.
나는 그것을 안다/proc/diskstats오버플로될 수 있지만, 그렇게 되면 일반적으로 숫자가 엄청나게 커집니다.
그래프를 좀 더 자세히 살펴보면 목요일이 그 전 주(및 몇 주)보다 더 급격하게 나타나는 것을 알 수 있습니다. 해당 기간에 대한 결과를 확대하면 다음과 같습니다.
0 또는 0에 가까운 읽기 간격은 비정상적이며 이것이 현실을 반영한다고 생각하지 않습니다. 목요일에 나타나기 시작했고 금요일까지 대부분의 판독값이 이제 0이 되도록 더 많은 로드를 추가함에 따라 요청 수가 일부 임계값을 초과했을 수 있습니다.
여기서 무슨 일이 일어나고 있는지에 대한 아이디어가 있는 사람이 있나요?
커널 버전 3.16.7-ckt11-1+deb8u3.