사용량이 많은 kjournald 이유

15

왜 kjournald내 컴퓨터에 열 이 나는지 알아 내려고 노력 중 입니다. 메모리가 많은 8 코어 박스입니다. CPU 부하가 ~ 50 %입니다.

iotop은 특정 프로세스를 가리 키지 않는 것 같습니다-여기저기서 약간의 쓰기가 발생합니다 (주로 cron 시작, 일부 모니터링 통계 생성 등) sys/vm/block_dump쓰기 통계를 수집하는 데 사용했을 때 다음과 같은 목록이 나타납니다.

kjournald(1352): 1909
sendmail(28934): 13
cron(28910): 12
cron(28912): 11
munin-node(29015): 3
cron(28913): 3
check_asterisk_(28917): 3
sh(28917): 2
munin-node(29022): 2
munin-node(29021): 2

어디 kjournald행동은 단지 기록이다.

왜 그런 일이? kjournald 활동을 조금 제한하기 위해 무엇을 봐야합니까? 실제로 쓰여지는 내용에 비례하지 않는 것 같습니다.

— 바이 랩터
소스

사용중인 OS uname 정보를 게시 할 수 있습니까?

— Soham Chakraborty

나는 똑같은 문제가 있었다

— 공유 된 Eayrs

15

kjournaldext3 저널 (저널링 파일 시스템)을 담당합니다. 특정 부하에서 많은 CPU를 사용하는 것으로 알려져 있습니다. 다른 파일 시스템을 사용하거나 저널링을 비활성화 (fs ext2를 효과적으로 만드는 것)하는 것 외에는 할 일이 많지 않습니다.

이론적으로 다른 ext3 저널링 모드 중 하나를 사용하여 CPU 사용량이 줄어드는 지 확인할 수 있지만 각 방법은 디스크에 기록되는 데이터의 안전성을 손상시킵니다. mode, writeback mode 및 'everything'모드를 주문했습니다.

순서 : 메타 데이터 만 저널링하지만 메타 데이터 변경 사항을 저널에 커미트하기 전에 메타 데이터와 관련된 데이터가 저장되도록합니다.
쓰기 저장 : 저널 전용 메타 데이터이지만 저널 커밋 전에 데이터가 저장된다는 보장은 없습니다.
저널 : 모든 것이 저널, 데이터 및 메타 데이터입니다. YMMV이지만 느릴 수 있습니다.

data=시스템을 장착 할 때 옵션을 사용하여 모드를 설정하십시오 ( 예 :) data=ordered.

— 코어 덤프
소스

저널링 모드를 변경하는 데있어 요점을 완전히 끄는 것과는 반대의 의미는 없지만 훨씬 더 의미가 없습니다. 그래서 저널 옵션이 무의미한 것을 설명하십시오.

— poige

3

다른 저널 모드는 다른 CPU 동작을 나타냅니다. 여기에 몇 가지 테스트가 있습니다 .

— 코어 덤프

1

@coredump, 여전히 무의미 합니다. 다른 저널링 모드에 대한 CPU 사용량을 보여주는 그래프는 없으며 처리량 만 있습니다. CPU 사용량 그래프는 실제로 FS 간의 차이점 만 보여줍니다. 또한 그래프에서 EXT3와 Reiser3 사이의 눈에 띄는 차이를 고려하면 전체 및 평균 CPU 풋 프린트가 분석 되는 것이 분명합니다 . 여기서 @viraptor에는 kjournald 활동이 있습니다.

— poige

우리는 동의하지 않을 것에 동의합니다. 그의 환경에서만 테스트하면 CPU 사용량에 차이가 있는지 여부가 표시됩니다. 또한 정부가 FS 작성자를 영구적으로 잠그기 때문에 ReiserFS를 권장하지 않습니다. :).

— coredump

8

여기,이 유머 컵을 가져

— 가세요

4

기본적으로 ext3 파일 시스템은 atimes가 켜진 상태로 마운트됩니다. 파일 또는 디렉토리를 읽거나 액세스 할 때마다 파일 시스템은이 시간 레코드를 업데이트하기 위해 디스크에 다시 써야합니다. 즉, 워크로드가 대부분 읽기 기반 인 경우에도 각 파일 및 디렉토리의 액세스 시간을 업데이트하기 위해 디스크에 충돌해야 kjournald하므로 프로세스가 왜 그렇게 많은 블록을 작성 했는지에 대한 추측 입니다.

시간을 끄면 성능이 크게 향상되지만 POSIX 준수는 중단됩니다. 한때 비판에 대한 토론은 이 위키 백과 기사 를 확인하십시오 .

시간을 끄 noatime려면 파일 시스템의 마운트 옵션을 추가 하거나 poige에서 제안한대로 다시 마운트 할 수 있습니다. 다음은 루트 파일 시스템의 예입니다.

mount -o remount,noatime /

— 에반 보스 트롬
소스

3

보다 최근의 커널은 기본적으로 와 relatime사이에서 허용 가능한 타협으로 보입니다 . noatimeatime

— Oliver

1

데이터의 완전성이 중요하지 않은 경우 :

iostat -o -a

실제로 kjournald인지 확인하십시오. 서버가 충돌하는 원인은 무엇입니까?

하드 드라이브를 SSD로 변경하면 작동합니다.

kjournald가 5-10MB의 데이터를 쓰는 것을 보았을 때

http://ubuntuforums.org/showthread.php?t=56621

sudo tune2fs -O ^has_journal /dev/sda1
sudo e2fsck /dev/sda1

여기서 sda1은 파티션 이름입니다.

추가로 확인할 수 있도록 결과를 주석으로보고하십시오.

— 공유 된 Eayrs
소스

3

iostat가 아니라 iotop을 의미합니까?

— Joe Niland

0

할 말이 아니라 다음과 같이 언급하십시오.

mount -oremount,noatime /fs/being_over/journaled— 빠른 추측으로 ( mount어쨌든 당신의 모습을 보여주지 않았습니다 )
저널 크기를 줄이십시오 ( tune2fs -J …)
Reiser3으로 전환 하십시오 (예 : 오랫동안 견고 함).

— 포이즌
소스