왜 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 활동을 조금 제한하기 위해 무엇을 봐야합니까? 실제로 쓰여지는 내용에 비례하지 않는 것 같습니다.
답변
kjournaldext3 저널 (저널링 파일 시스템)을 담당합니다. 특정 부하에서 많은 CPU를 사용하는 것으로 알려져 있습니다. 다른 파일 시스템을 사용하거나 저널링을 비활성화 (fs ext2를 효과적으로 만드는 것)하는 것 외에는 할 일이 많지 않습니다.
이론적으로 다른 ext3 저널링 모드 중 하나를 사용하여 CPU 사용량이 줄어드는 지 확인할 수 있지만 각 방법은 디스크에 기록되는 데이터의 안전성을 손상시킵니다. mode, writeback mode 및 ‘everything’모드를 주문했습니다.
- 순서 : 메타 데이터 만 저널링하지만 메타 데이터 변경 사항을 저널에 커미트하기 전에 메타 데이터와 관련된 데이터가 저장되도록합니다.
- 쓰기 저장 : 저널 전용 메타 데이터이지만 저널 커밋 전에 데이터가 저장된다는 보장은 없습니다.
- 저널 : 모든 것이 저널, 데이터 및 메타 데이터입니다. YMMV이지만 느릴 수 있습니다.
data=시스템을 장착 할 때 옵션을 사용하여 모드를 설정하십시오 ( 예 🙂 data=ordered.
답변
기본적으로 ext3 파일 시스템은 atimes가 켜진 상태로 마운트됩니다. 파일 또는 디렉토리를 읽거나 액세스 할 때마다 파일 시스템은이 시간 레코드를 업데이트하기 위해 디스크에 다시 써야합니다. 즉, 워크로드가 대부분 읽기 기반 인 경우에도 각 파일 및 디렉토리의 액세스 시간을 업데이트하기 위해 디스크에 충돌해야 kjournald하므로 프로세스가 왜 그렇게 많은 블록을 작성 했는지에 대한 추측 입니다.
시간을 끄면 성능이 크게 향상되지만 POSIX 준수는 중단됩니다. 한때 비판에 대한 토론은 이 위키 백과 기사 를 확인하십시오 .
시간을 끄 noatime려면 파일 시스템의 마운트 옵션을 추가 하거나 poige에서 제안한대로 다시 마운트 할 수 있습니다. 다음은 루트 파일 시스템의 예입니다.
mount -o remount,noatime /
답변
데이터의 완전성이 중요하지 않은 경우 :
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은 파티션 이름입니다.
추가로 확인할 수 있도록 결과를 주석으로보고하십시오.
답변
할 말이 아니라 다음과 같이 언급하십시오.
mount -oremount,noatime /fs/being_over/journaled— 빠른 추측으로 (mount어쨌든 당신의 모습을 보여주지 않았습니다 )- 저널 크기를 줄이십시오 (
tune2fs -J …) - Reiser3으로 전환 하십시오 (예 : 오랫동안 견고 함).