유해한 USB 스틱이 걸리는 문제- LWN.net, 2013년 11월.
Artem S. Tashkinov는 최근 적어도 일부 LWN 독자에게 친숙한 문제에 직면했습니다. 느린 저장 장치(예: USB 스틱 또는 미디어 플레이어)를 Linux 컴퓨터에 연결하고 대량의 데이터를 씁니다.전체 시스템이 계속 중단됩니다., 이는 몇 분 동안 지속될 수 있습니다.
그러나 이번에 Artem은 흥미로운 관찰을 했습니다. 64비트 커널로 실행하면 시스템이 정지되지만 동일한 하드웨어에서 32비트 커널을 사용할 때는 그러한 문제가 발생하지 않았습니다.
이 기사에서는 64비트 커널의 경우 더티 페이지 캐시(쓰기 저장 캐시)가 기본적으로 메모리의 20%까지 증가할 수 있다고 설명합니다. 32비트 커널의 경우 실제로는 180MB로 제한됩니다.
Linus는 64비트에서 이를 ~180MB로 제한할 것을 권장하지만 현재 Linux(v4.18)에서는 이를 수행하지 않습니다. 비교하다리누스가 제안한 패치,도착하다현재 기능리눅스 4.18에서. 그러한 변화에 반대하는 가장 큰 주장은 Dave Chinner에게서 나옵니다. 그는 버퍼링을 너무 많이 줄이면 파일 시스템이분열로 고통받다. 그는 아직설명했다"스트리밍 IO의 경우 일반적으로 최소 5초의 캐싱이 필요합니다.더러운지연을 제거하기 위한 데이터입니다. "
혼란스러워요. USB 스틱의 작동이 중지되어 전체 시스템이 중단되는 이유는 무엇입니까?
코드를 설명하는 이전 기사를 읽었기 때문에 혼란스럽습니다.2011년 합병(리눅스 3.2). 이는 커널이 장치별로 더티 페이지 캐시를 제어해야 함을 나타냅니다.
I/O 더티 스로틀링 없음- LWN.net, 2011
Fengguang의 패치 세트가 들어오는 곳입니다. 그는 주어진 시간에 각 프로세스가 얼마나 많은 페이지를 더티로 허용해야 하는지 결정할 수 있는 제어 루프를 만들려고 했습니다. 제한을 초과하는 프로세스는 쓰기 저장 시스템이 이를 따라잡을 수 있도록 일정 기간 동안 절전 모드로 전환됩니다.
[...]
시스템의 목표는 더티 페이지 수를 설정된 값으로 유지하는 것입니다. 문제가 발생하면 원래 위치로 되돌리기 위해 점점 더 많은 힘이 가해집니다.
[...]
그러나 이 비율은 지원 장치(BDI)를 고려하지 않고는 실제로 계산할 수 없습니다. 프로세스는 지정된 BDI에 더티 페이지를 저장할 수 있으며 시스템에는 현재 너무 많은 더티 페이지가 있을 수 있습니다. 그러나 해당 프로세스를 제한하는 것이 현명한지 여부는 해당 BDI에 존재하는 더티 페이지 수에 따라 달라집니다. [...] 더티 페이지 수가 적은 BDI는 백로그를 신속하게 지울 수 있으므로 시스템이 원하는 것보다 더 더티하더라도 더 많은 더티 페이지를 허용할 수 있습니다. 따라서 패치 세트는 특정 BDI가 자체 설정 지점 및 관찰된 대역폭에서 얼마나 떨어져 있는지 확인하는 복잡한 공식을 사용하여 특정 BDI에 대해 계산된 pos_ratio를 조정합니다. 최종 결과는 시스템이 주어진 BDI에 의해 지원되는 페이지를 더 많거나 적게 더티해야 하는지 여부와 더티 정도를 설명하는 수정된 pos_ratio입니다.
이보다 더 일찍 장치별 컨트롤이 추가되었습니다.더욱 스마트해진 쓰기 제한, 2007 LWN.net.[패치 0/23] 기기별 더티 제한-v10. 그것은 병합된다리눅스 버전 2.6.24.
답변1
- 2013년 기사에 오류가 있습니다.
- LWN에 오류가 있나요? 확실합니까?
- "백그라운드" 쓰기 저장으로 생성된 I/O 장치의 긴 대기열
- "I/O 더티 스로틀링 없음"의 제한 사항은 무엇입니까?
- "USB Stall" 문제에 대한 실제 보고서
- 잘못된 먼지 제한 계산 [2014]
- 대형 페이지 할당 차단 IO [2011]
- "더티 페이지가 LRU 끝에 도달했습니다"? [2013년 이전]
1. 2013년 기사에는 오류가 있습니다.
"USB 플래시 드라이브 정지"라는 기사는 매우 오해의 소지가 있는 인상을 줍니다. 이는 원본 보고서와 다양한 답변을 잘못 표현했습니다.
Artem이 캐시된 쓰기를 USB 스틱에 플러시할 때 Artem은 전체 시스템 정지를 보고하지 않습니다. 그의원본 보고서"sync" 명령을 실행하는 데 "수십 분"이 걸릴 수 있다고 불평합니다. 이 차이점은 다음과 같습니다.리누스 토발즈의 답변:
실제로 복사는 일반 USB 키를 들고 거기에 쓰기를 시도하는 것만큼 간단합니다. 방금 임의의 ISO 이미지로 작업을 수행했는데, 이는 고통스러웠습니다.백그라운드에서 대부분의 다른 작업을 수행하는 것이 고통스럽다는 것은 아니지만 "동기화"된 작업(그리고 스크립트에서 발생하는 작업)을 실행하면 작업이 중단될 것입니다.몇 분.
2.LWN에 오류가 있나요? 확실합니까?
존 코베트15년의 경험을 갖고 있으며 매주 Linux 커널 개발에 대해 보고하고 있습니다. 나는 이 글이 적어도 그럴 것이라고 예상했다.폐쇄어떤 의미에서는 올바르게 이해하십시오. 그래서 나는 이 두 가지 다른 기록을 처리하여 그들이 동의하거나 동의하지 않는 세부 사항을 찾아내고 싶습니다.
나는 다 읽었다원래 토론, lore.kernel.org의 아카이브를 사용합니다. 메시지가 매우 명확하다고 생각합니다.
나는 이 기사가 토론을 오해했다고 100% 확신합니다. 기사 아래 댓글에는 적어도 두 명의 독자가 자신의 말로 잘못된 주장을 반복했지만, 이를 정정하는 사람은 아무도 없었다. 이 기사는 세 번째 단락에서 혼란을 계속합니다.
이 모든 데이터는 I/O 대기열을 막아 잠재적으로 다른 작업을 지연시킵니다. 그리고 누군가 전화하는 한동기화(), 전체 대기열이 기록될 때까지 작업이 중단됩니다.
Linus는 "그냥 비명을 지르며 멈췄습니다"라고 말하는데 이는 혼란스러울 수 있습니다. "Thing"은 "무엇이든 하라 sync"는 뜻입니다. 그러나 Corbett는 "그 것"이 "전체 시스템"을 의미하는 것처럼 썼습니다.
Linus에 따르면 이것은 실제 문제입니다. 하지만 그것은 대부분의 "사물"에 해당됩니다.아니요시스템 전체의 sync() 작업을 호출합니다. [1]
Corbett가 이것을 "전체 시스템"과 혼동하는 이유는 무엇입니까? 나는 많은 문제가 발생하고 잠시 후에 그것들을 모두 분리하기가 어렵다고 생각합니다 :-). LWN이 장치별(및 프로세스별) 더티 제한의 개발을 설명하지만 일반적으로 그러한 세부 사항에 대해 많이 쓰여진 것 같지 않습니다. 많은 문서에서는 전역 더티 한도 설정만 설명합니다.
3. "백그라운드" 쓰기 저장으로 인해 생성된 I/O 장치의 긴 대기열
Artem 게시됨두 번째 보고서스레드에서 "서버가 거의 정지되고 다른 IO 요청을 완료하는 데 더 많은 시간이 걸립니다."
두 번째 보고서는 USB 스틱이 걸려 있다는 주장과 일치하지 않습니다. 10GB 파일을 생성한 후 발생합니다.내부디스크. 이것은 다른 질문입니다.
보고서에서는 더티 한도를 변경하여 이 문제를 개선할 수 있는지 여부를 확인하지 않았습니다. 최근 이러한 사례가 분석되었습니다. 기본 디스크의 I/O 대기열이 막히면 심각한 문제가 발생합니다. 요청 시 프로그램 코드를 로드하고 write() + fsync()를 사용하여 문서 및 응용 프로그램 데이터를 저장하는 등 자주 사용하는 디스크에서 긴 지연이 발생할 수 있습니다.
성가신 백그라운드 쓰기 저장을 줄입니다.——LWN.net, 2016
메모리 관리 코드가 일련의 더티 데이터를 쓰기로 결정하면 결과적으로 블록 하위 시스템에 I/O 요청이 제출됩니다. 요청은 I/O 스케줄러에서 다소 시간이 걸릴 수 있지만 결국 대상 장치의 드라이버로 전달됩니다.
문제는 쓸 더티 데이터가 많으면 장치에 대기 중인 요청 수가 수천 개에 달할 수 있다는 것입니다. 합리적으로 빠른 드라이브라도 너무 많은 요청을 처리하는 데 시간이 걸릴 수 있습니다. 다른 활동(예: 웹 브라우저에서 링크 클릭 또는 애플리케이션 실행)이 동일한 장비에서 I/O 요청을 생성하는 경우 이러한 요청은 긴 대기열의 뒤쪽에 대기하게 되며 해당 요청에는 사용하지 못할 수 있습니다. 잠시 봉사하십시오. 여러 개의 동시 요청이 생성되는 경우(예: 새로 시작된 응용 프로그램에서 생성된 페이지 오류) 각 요청은 이 긴 대기열을 차례로 통과해야 할 수 있습니다. 모든 것이 정지된 것처럼 보이는 순간입니다.
[...]
대부분의 블록 드라이버는 내부적으로 자체 대기열도 유지합니다. 이러한 하위 수준 대기열은 요청이 도착하면 더 이상 I/O 스케줄러(있는 경우)의 제어를 받지 않기 때문에 특히 문제가 될 수 있습니다.
이를 개선하기 위해 패치를 병합했습니다.2016년 말(리눅스 4.10). 이 코드를 "쓰기 저장 제한" 또는 WBT라고 합니다. 온라인으로 검색해 보니 wbt_lat_usec이에 대한 더 많은 이야기가 나왔습니다. (원본 문서는 이것에 대해 작성했지만 wb_lat_usec오래되었습니다.) CFQ 또는 BFQ I/O 스케줄러에는 쓰기 저장 제한이 적용되지 않습니다. CFQ는 Linux v4.20 이전의 기본 커널 빌드를 포함하여 기본 I/O 스케줄러로 널리 사용되었습니다. CFQ는 커널 v5.0에서 제거되었습니다..
문제(및 프로토타입 솔루션)를 설명하기 위한 테스트를 진행합니다.SSD(NVMe처럼 보임) 및 "일반 하드 드라이브". 하드 드라이브는 "대규모 버스트 IO가 있는 더 깊은 대기열 깊이 장치만큼 나쁘지 않습니다."
대기열에 있는 요청이 "수천"인지는 잘 모르겠지만 적어도 수백 개의 요청을 대기열에 넣을 수 있는 NVMe 장치가 있습니다. 대부분의 SATA 하드 드라이브는 32개의 요청을 대기열에 넣을 수 있습니다("NCQ"). 물론 하드 드라이브는 각 요청을 완료하는 데 더 오랜 시간이 걸립니다.
4. "I/O 더티 스로틀링 없음"의 제한 사항은 무엇입니까?
"I/O 더티 스로틀링 없음"은 상당히 복잡한 엔지니어링 시스템입니다. 그것도 시간이 지나면서 적응이 됐다. 분명 있었고 지금도 그럴 거야일부이 코드 내의 제한 사항.
LWN 기사, 코드/패치 노트 및슬라이드쇼상세한 시연에서 볼 수 있듯이, 많은 수의 시나리오가 고려되었습니다. 여기에는 악명 높은 느린 USB 스틱과 빠른 호스트 드라이브가 포함됩니다. 테스트 케이스에는 "1000개의 동시 dds"(즉, 순차 작성기)라는 문구가 포함되어 있습니다.
지금까지 더티 제한 코드의 제한 사항을 시연하고 재현하는 방법을 모르겠습니다.
더티 제한 코드의 범위를 벗어나는 문제에 대한 수정 사항에 대한 몇 가지 설명을 보았습니다. 내가 찾은 최신 수정 사항은 2014년에 있었습니다. 다음 섹션을 참조하세요. LWN에서 다루는 주제 중에서 우리는 다음을 배웠습니다.
지난 몇 가지 릴리스에서 이와 같은 문제는 많은 더티 페이지/불충분한 쓰기 저장을 보는 데 지쳐서 IO가 완료될 때까지 기다리게 되는 회수 문제로 인해 발생했습니다.
[...] systemtap 스크립트는 이러한 유형의 영역을 캡처했으며 수정되었다고 생각합니다.
멜 고먼 역시설명하다몇 가지 "미해결 문제"가 있습니다.
그러나 여전히 문제가 있습니다. 모든 더티 페이지가 느린 장치에 의해 백업되는 경우 더티 제한으로 인해 결국 더티 페이지 밸런싱이 중단됩니다 [...]
이 기사는 LWN의 설명을 거의 뒷받침하는 보고된 토론 스레드에서 내가 찾을 수 있는 유일한 것입니다. 이것이 무엇을 의미하는지 이해할 수 있었으면 좋겠습니다. 또는 이를 설명하는 방법과 Artem 및 Linus가 실행한 테스트에서 중요한 문제가 아닌 것처럼 보이는 이유는 무엇입니까?
5. "U 디스크 스턱" 문제에 대한 실제 보고서
Artem이나 Linux 모두 전체 시스템에 영향을 미치는 "USB 스틱 정지"를 보고하지 않았지만 다른 곳에서 이 문제에 대한 일부 보고서를 찾을 수 있습니다. 여기에는 마지막으로 알려진 수정 이후 최근 몇 년간의 보고서가 포함됩니다.
차이점이 무엇인지 모르겠습니다. 어쩌면 테스트 조건이 어떤 면에서 다를 수도 있고, 2013년 이후 커널에 새로운 문제가 있을 수도 있습니다.
- https://utcc.utoronto.ca/~cks/space/blog/linux/USBDrivesKillMyPerformance/https://utcc.utoronto.ca/~cks/space/blog/linux/FishingUSBDriveResponsiveness[2017]
- 파일을 펜 드라이브에 복사할 때 컴퓨터가 정지되는 이유는 무엇입니까?[2014 년 1 월]
- 외부 디스크에서 과도한 읽기/쓰기 작업을 수행할 때 시스템이 지연됩니다.[2018]
- 과도한 디스크 I/O를 수행할 때 Linux GUI가 응답하지 않게 됩니다. 무엇을 조정해야 합니까?[2019]
6. 오염기준 계산 오류 [2014]
2014년 1월에 흥미로운 수정 사항이 있었습니다(커널 v3.14에 적용됨). 질문에서는 기본 제한이 메모리의 20%로 설정되어 있다고 말했습니다. 실제로 더티 페이지 캐시에 사용할 수 있는 메모리의 20%로 설정되어 있습니다. 예를 들어 커널은 TCP/IP 네트워크 소켓에서 보낸 데이터를 버퍼링합니다. 소켓 버퍼는 삭제하거나 더티 페이지 캐시로 교체할 수 없습니다 :-).
문제는 커널이 더티 페이지 캐시를 지원하기 위해 데이터를 교환할 수 있는 것처럼 교환 가능한 메모리를 계산한다는 것입니다. 이론적으로는 가능하지만 커널은 스와핑을 피하고 페이지 캐시를 삭제하는 것을 강력히 선호합니다. 이 문제는 느린 USB 스틱에 쓰기 작업을 포함하고 이로 인해 전체 시스템이 정지된다는 점을 지적하는 테스트로 설명되었습니다. :-).
바라보다답변: [패치 0/2] mm: 대규모 익명 및 더티 캐시에 대한 재활용 일시 중지를 줄입니다.
해결 방법은 dirty_ratio이제 이를 파일 캐시의 일부로만 처리하는 것입니다.
이 문제를 겪은 커널 개발자에 따르면 "트리거 조건은 높은 익명 메모리 사용량, 많은 버퍼링된 IO, 스왑 구성 등 상당히 합리적인 것으로 보이며 실제로 이러한 일이 발생할 가능성이 높습니다." 이것이 이유를 설명할 수 있습니다.일부2013년 또는 그 이전의 사용자 보고서입니다.
7. IO 시 대형 페이지 할당 차단[2011]
또 다른 질문은 다음과 같습니다.거대한 페이지, 느린 드라이버 및 긴 대기 시간(LWN.net, 2011년 11월). 이제 대형 페이지의 문제는 다음과 같습니다.안정적인.
그리고 기사에 나와 있는 내용과 상관없이 제 생각에는대부분의 최신 Linux PC는 대용량 페이지를 실제로 사용하지 않습니다.. Debian 10부터는 변경될 수 있습니다. 그러나 데비안 10은 가능할 때마다 거대한 페이지를 할당하기 시작하지만, 나에게는 그것이 분명해 보입니다.지연을 일으키지 않고defrag, 다른 설정을 '항상'으로 변경하지 않는 한 .
8. "더티 페이지가 LRU 끝에 도달함" [2013년 이전]
나는 이것을 조사하지 않았지만 흥미로운 것을 발견했습니다.
모건 2011: 동기식 압축 쓰기로 인해 발생하는 새로운 USB 관련 지연입니다. 과거에는 더티 페이지가 LRU 끝에 도달하는 것이 가장 큰 문제였습니다.그리고 reclaim으로 작성되었습니다..
모건 2013: 이 일반적인 작업 영역은 LRU 끝에 도달하는 더티 페이지와 같은 문제를 처리합니다.(CPU 사용량이 너무 높습니다)
이것이 두 가지 다른 "LRU 끝 도달" 문제라면 첫 번째 문제는 아마도 정말 안 좋은 것처럼 들릴 것입니다. 더티 페이지가 최근에 가장 적게 사용된 페이지가 되면 더티 페이지 쓰기가 완료될 때까지 메모리 할당 시도가 지연되는 것처럼 들립니다.
그것이 무엇을 의미하든 그는 이제 문제가 해결되었다고 말합니다.
[1] 한 가지 예외: 한동안 데비안 패키지 관리자는 dpkg성능을 향상시키기 위해 sync()를 사용했습니다. 이는 sync()가 오랜 시간이 걸릴 수 있는 정확한 문제로 인해 제거되었습니다. 그들은 Linux에서 사용되는 방법으로 전환했습니다 sync_file_range(). 바라보다우분투 버그 #624877, 댓글 62개.
이 질문의 일부에 답하기 전에 다음은 중복되어야 합니다.
저는 Artem의 두 보고서를 "I/O 더티 스로틀링 없음" 코드와 일치하는 것으로 해석할 수 있다고 생각합니다.
더티 조절 코드의 목적은 각 지원 장치가 "다른 장치에 비해 현재 평균 쓰기 속도를 기준으로" "총 후기입 캐시"를 공평하게 공유하도록 허용하는 것입니다. 문구는 문서에서 나왔습니다./시스템/클래스/bdi/.[2]
가장 간단한 경우에는 하나의 지원 장치만 작성됩니다. 이 경우 장치의 공정한 점유율은 100%입니다. write() 호출은 전체 쓰기 저장 캐시를 제어하고 "설정 지점"으로 유지하기 위해 조절됩니다.
dirty_background_ratio쓰기는 백그라운드 쓰기가 시작되는 지점과 후기입 캐시의 엄격한 제한 dirty_ratio사이의 중간에서 조절되기 시작합니다. 기본적으로 이는 각각 사용 가능한 메모리의 10%와 20%입니다.
예를 들어 기본 디스크에는 데이터의 최대 15%까지만 쓸 수 있습니다. 보유하고 있는 RAM의 양에 따라 기가바이트의 캐시된 쓰기가 있을 수 있습니다. 이 시점에서 write() 호출은 쓰기 저장 속도와 일치하도록 조절되기 시작하지만 이는 문제가 되지 않습니다. 중단 문제는 read() 및 fsync() 호출과 관련된 것으로 예상됩니다. 이 호출은 관련되지 않은 많은 IO 뒤에 갇히게 됩니다. 이는 "쓰기 저장 제한" 코드가 해결하는 특정 문제입니다. 일부 WBT 패치 제출에는 이로 인한 끔찍한 지연을 보여주는 문제 설명이 포함되어 있습니다.
마찬가지로 USB 스틱에 기록하면 최대 15%까지 완전히 채울 수 있습니다. USB에 대한 추가 쓰기()가 제한됩니다. 그러나 기본 디스크는 공평한 분배를 사용하지 않습니다. 기본 파일 시스템에서 write() 호출을 시작하면 조절되지 않거나 최소한 지연 시간이 훨씬 줄어듭니다. 내 생각에는 USB write()가 두 작성자의 균형을 맞추기 위해 더 제한될 것이라고 생각합니다.
전체 쓰기 저장 캐시가 일시적으로 설정 값 이상으로 상승할 수 있을 것으로 예상됩니다. 좀 더 까다로운 경우에는 전체 쓰기 저장 캐시에 대한 엄격한 제한에 도달할 수 있습니다. 하드 제한은 기본적으로 사용 가능한 메모리의 20%입니다. 구성 옵션은 dirty_ratio/ 입니다 dirty_bytes. 어쩌면 장치 속도가 느려지고(아마도 무작위 I/O 패턴으로 인해) 더티 스로틀링이 속도 변화를 즉시 인식하지 못하기 때문에 이 문제가 발생할 수 있습니다.
[2] 이 문서에서는 다음을 수행할 수 있다고 제안합니다.수동특정 파티션/파일 시스템에 사용할 수 있는 후기입 캐시의 비율을 제한합니다. 이 설정을 /sys/class/bdi/*/max_ratio"인식" 이라고 합니다 .제한하려는 장치가 현재 쓰고 있는 유일한 장치인 경우 제한은 큰 영향을 미치지 않습니다.".
답변2
2024년 2월 현재 이 문제는 해결되지 않은 상태로 남아 있습니다.
다음을 포함하는 콘텐츠를 생성하여 이 문제를 해결/해결할 수 있습니다 /etc/sysctl.d/limit_dirty_caches.conf.
# Per Linus Torvalds advice
vm.dirty_background_bytes = 33554432
vm.dirty_bytes = 134217728
일반적인 sysctl 규칙은 다음과 같습니다.최적이 아닌대용량 파일을 복사/생성할 때 조각화 수준이 높아질 수 있기 때문입니다. 계속 읽어주세요.
/sys/class/bdiLinux 6.2부터는 이 동작을 구성하기 위해 sysfs API (예: strict_limit, min_bytes, max_bytes, min_ratio_fine, ) 에 다시 작성된 새로운 블록 장치 인터페이스가 있지만 max_ratio_fine불행히도 누군가 USB 장치에 맞게 조정해야 했지만 아무도 그렇게 하지 않았습니다.
https://docs.kernel.org/admin-guide/abi-testing.html#abi-file-testing-sysfs-class-bdi
간단한 udev규칙으로 이 문제를 영원히 해결할 수 있습니다.