나는 항상 nohup시스템을 부팅하는 데 사용합니다. 그러나 출력이 너무 nohup커서 이를 /dev/null./dev/null
아니면 코드 수준까지 드릴다운하여 이러한 로그 메시지를 모두 제거해야 합니까? (그러나 필요할 수도 있습니다).
유일한 관심사는 I/O 활용률과 파일 크기입니다.
답변1
기록된 데이터는 /dev/null아무데도 가지 않습니다. 파일을 쓰지 않으므로 파일 크기에 영향을 미치지 않습니다.
프로그램이 를 쓰면 /dev/null시스템 호출이 발생합니다. 그러나 시스템 호출은 어디에도 데이터를 쓰지 않고 거의 즉시 반환됩니다. 따라서 애플리케이션 관점에서는 I/O가 있지만 하드웨어 관점에서는 그렇지 않습니다.
편지를 쓰는 데 드는 작은 비용이 너무 큰지 여부는 당신 외에는 아무도 모릅니다 /dev/null. 고민된다면 벤치마킹해보세요.
답변2
좀 그런 느낌이에요XY 문제. 실제로 해야 할 일은 구성 파일이나 점점 더 많은 의 를 사용하는 명령줄을 통해 로깅 수준을 제어하는 기능을 추가하는 것입니다 -v. -vvv많은 명령줄 도구와 마찬가지로.
nohup그런 다음 추가/제거 토글을 사용하여 서버를 호출 -vv..하고 필요한 경우에만 추가할 수 있습니다.
또한 실제 로깅 도구를 사용하는 방법도 살펴보세요.log4j,log4perl, log4X 여기서 X는 귀하의 언어입니다. 그런 다음 log4X .conf 파일에서 로깅 수준을 제어하고 로그 회전과 같은 항목을 지정할 수도 있습니다.
분명히 로깅을 있는 그대로 리디렉션할 수 있지만 /dev/null개발자는 이러한 다른 옵션도 고려해야 합니다.
답변3
/dev/null에 쓰는 데는 비용이 0이 아니지만 시스템 성능에 영향을 준다면 소프트웨어 작성자가 뭔가 큰 잘못을 한 것입니다. sys_write() 호출은 고도로 최적화되어 있습니다. 전송된 데이터 쓰기는 빈 드라이버에 도달할 때까지 다양한 라이브러리와 커널 시스템을 거칩니다. 이 길은 매우 효율적입니다.
예, 프로그램에는 출력을 비활성화하는 플래그가 있어야 하지만 그렇지 않고 /dev/null에 쓰면 성능 문제가 발생하는 경우 이상한 시스템이 있는 것입니다.
"성급한 최적화는 모든 악의 근원이다"를 기억하십시오. 이 문제를 해결하기 위해 코드를 편집하는 것은 이것이 실제로 가장 큰 성능 병목 현상임을 보여주는 벤치마크를 먼저 작성할 수 없다면 시간 낭비입니다.
역사적 기록:
Linux의 원래 버전은 /dev/null이 매우 느렸습니다. 마지막에 데이터를 버리기 위해 많은 처리를 수행합니다. Linux의 /dev/null이 FreeBSD 및 Solaris(당시 인기 있는 Unix 계열 시스템)보다 훨씬 느리다는 것을 보여주는 당황스러운 벤치마크(죄송합니다, 링크를 찾을 수 없습니다!)가 있습니다. 다음 버전의 Linux에서는 /dev/null이 더 빨라질 것입니다. 마찬가지로 Linux의 루프백 NIC는 패킷을 완전히 처리하고 CRC 오류(틀릴 수 없음)를 확인하고 기타 불필요한 작업을 수행했기 때문에 매우 느렸습니다. 당황스러울 정도로 나쁜 벤치마크가 공개되었고 문제가 신속하게 수정되었습니다.