Hacker News 의견들

• 작성자인 나임. 지난번 커널 버그 관련 글 이후, JVM이 자체적으로 스레드 활동을 보고하는 방식을 살펴봤음
  “이 스레드의 CPU 사용 시간은 얼마인가?”라는 질문이 생각보다 너무 비싼 연산이라는 걸 알게 되었음
  • 나노초 단위의 측정을 논하려면 시계의 안정성과 정확도를 매우 잘 이해해야 함
    원자시계 수준의 기준이 없다면 절대적인 수치를 주장하기 어렵다고 생각함
  • 분포가 여러 자릿수 단위로 퍼져 있는 이유를 살펴봤는지 궁금함. 그 자체로 흥미로운 현상임
  • 짧은 TL;DR 요약이 정말 고마웠음. 이런 요약이 글의 진입 장벽을 낮춰주고 읽는 동기를 만들어줌
  • “놀랍지 않음(Quelle Surprise)”이라는 반응을 남김
• clock_gettime()은 vDSO를 통해 컨텍스트 스위치를 피함. 그래서 flamegraph에서도 그 흔적이 보임
  • 하지만 일부 clock만 해당됨. CLOCK_VIRT나 CLOCK_SCHED 같은 경우는 여전히 syscall 호출이 필요함
  • vDSO 프레임 아래를 보면 여전히 syscall이 있음. 특정 clock id에 대한 빠른 경로(fast path) 가 구현되어 있지 않은 듯함
  • CLOCK_THREAD_CPUTIME_ID는 결국 커널로 넘어감. task struct를 참조해야 하기 때문임
    관련 커널 소스는 posix-cpu-timers.c,
    cputime.c,
    gettimeofday.c 참고
• PERF_COUNT_SW_TASK_CLOCK을 사용하면 약 8ns 수준의 측정도 가능함
  perf_event_mmap_page를 통해 공유 페이지에서 읽고, rdtsc 호출로 델타를 계산하는 방식임
  문서화가 잘 안 되어 있고 오픈소스 구현도 거의 없음
  • 정말 멋진 트릭임. 다만 perf_event 설정과 권한 요구가 크기 때문에 긴 수명의 스레드에 적합해 보임
  • seqlock이 필요한 이유를 물음. 페이지 값과 rdtsc 사이에서 컨텍스트 스위치가 일어나지 않도록 하기 위함인지 궁금함
    아마 rdtsc 후 페이지 값을 다시 확인해 바뀌었으면 재시도하는 구조로 보임
    참고로 clock_gettime도 vdso 기반 가상 syscall임
  • clock_gettime은 syscall이 아니라 vdso를 사용함
• Flamegraph는 정말 훌륭한 도구임
  코드만 봤을 땐 괜찮아 보이지만, flamegraph를 보면 “이게 뭐야?!” 싶을 때가 많음
  정적 초기화가 아닌 초기화, 한 줄짜리 로거 호출이 비싼 직렬화를 유발하는 등 여러 문제를 발견했음
  • 나는 icicle graph도 좋아함. flamegraph의 반대 방향으로 누적되어, 여러 경로가 공통 라이브러리를 호출할 때 병목을 보기 쉬움
  • 이 SVG 예시를 새 탭에서 열면 인터랙티브 줌이 가능함
  • 성능 프로파일링과 최적화 실험은 개발에서 가장 즐거운 부분 중 하나임. “왜 저게 이렇게 느리지?”라는 놀라움이 많음
  • 문자열 파싱과 memoization의 조합이 이상하게 들린다는 의견도 있었음. 실제로는 비싼 정규식 패턴 파싱을 캐싱하지 않아 생긴 문제였음
  • flamegraph를 처음 써보려는 사람에게는 기본 개념과 시작점을 물어봄
• “이미지 새 탭에서 열기”가 실제로 SVG 인터랙션을 제공한다는 점이 놀라웠음
  • 이 기능은 Brendan Gregg의 FlameGraph 스크립트 덕분임
    평소엔 async-profiler의 HTML 생성기를 쓰지만, 이번엔 단일 SVG를 위해 Brendan의 도구를 사용했음
• OpenJDK 패치 작성자인 나임. /proc을 읽을 때의 메모리 오버헤드와 eBPF 프로파일링, 그리고 문서화가 부족한 user-space ABI의 역사를 다뤘음
  자세한 내용은 내 블로그 글에 정리했음
  • 왜 원래 구현이 그렇게 되어 있었는지 궁금하다는 질문을 받음. 매 호출마다 파일 IO와 문자열 파싱을 하는 건 비효율적이지만, 당시엔 이유가 있었을 것이라 생각함
  • Jaromir가 내 글을 보고 “나도 같은 시기에 초안을 썼다”며 서로의 글을 링크함. 내 글이 더 엄밀하다고 평가해줘서 기뻤음
• C나 C++ 같은 시스템 언어라고 해서 항상 빠른 건 아님. 무엇을 하느냐에 따라 속도는 크게 달라짐
• vDSO를 통한 읽기는 커널 전환, 버퍼 직렬화, 파싱 과정을 피하기 때문에 훨씬 빠름
• “2배 빨라졌다면 똑똑한 짓을 한 것일 수 있고, 100배 빨라졌다면 멍청한 짓을 멈춘 것일 뿐”이라는 인용을 공유함
  출처 트윗
• QuestDB 팀은 이 분야에서 최고 수준임. 사람들도, 소프트웨어도 모두 훌륭함
  Jaromir의 블로그도 정말 멋졌음