sync 명령은 무엇을합니까?

나는 그것이 무엇을하는지 알고 있습니다 ... 왜 그것이 내가 상속 한 응용 프로그램의 문제를 해결하고 있는지 궁금합니다. 나는 많은 플렉스 클라이언트의 Red5 서버 역할을하는 상당히 큰 바람둥이 응용 프로그램을 인수하고 많은 실시간 상호 작용 데이터를 처리하여 결국 레일 API로 플러시됩니다. 문제는 시간이 지남에 따라 많은 부하를 받았으며 이러한 클라이언트에 대한 resposes는 일반적으로 100ms 미만인 3-400ms로 증가했습니다. 클라이언트는 우리가 실제로 확인할 수없는 메모리 문제라고 의심했습니다. 어느 날 스테이징 서버에서 요청이 기본적으로 중단되어로드 테스트를 실행 중이거나 매우 느 렸습니다. 내가 보낸 변덕에

sync && echo 3 > /proc/sys/vm/drop_caches

마술처럼 서버는 다시 생명을 불어 넣고이 연결을 제공하는 최고 속도로 실행하기 시작했습니다. 이것이 우연의 일치입니까, 아니면이 행동이 의미가 있고 왜 그런가요?

모든 하드 디스크는 RAM보다 훨씬 느리므로 리눅스는 파일 시스템 데이터를 캐시하기 위해 떠 다니는 여분의 RAM을 사용합니다. 그러나 하드 디스크에 문제가 있거나 서버의 서비스가 서버가 데이터를 캐시하거나 검색 할 수 없을 때까지 너무 높은 속도로 데이터를 쓰려고 시도하지 않는 한 실제로 성능 문제를 일으키지 않아야합니다. 하드 디스크 수명이 다했다는 신호일 수도 있습니다.

아무리 해도:

• running man sync은 동기화가 무엇인지 알려줍니다.
• 인터넷 검색 'linux drop_caches'는 3 번을 에코하면 불필요한 모든 메모리 페이지가 캐시에서 해제된다는 것을 알려줍니다 [건강한 시스템에는 필요하지 않음]
• command1 && command2 'command1이 성공적으로 완료되면 command2를 실행하십시오'로 분류됩니다.
  • 이것의 파트너는 command1 || command2일명 'command1이 실패하면 command2를 실행하십시오'

주어진 명령 은 기껏 해야 임시 수정 이며 시스템에 다른 문제가 있음을 나타냅니다. 디스크의 수명이 다했거나 디스크로 수행중인 작업에 대한 시스템 전원이 너무 부족하거나 둘 다 입니다.

AWS는 희미한 마음이 아니며, 그 이유 중 하나를 만났습니다. AWS의 열악한 디스크 I / O 상황은 잘 알려져 있으며이를 기반으로 애플리케이션을 구축하는 모든 사람이 고려해야 할 주요 요인 중 하나입니다. 디스크 최적화 인스턴스와 문제를 개선하려고 시도 할 수있는 몇 가지 다른 트릭 (예 : EBS 볼륨에서 RAID 0 빌드)이 있습니다. 커널이 디스크 I / O를 버퍼링 할 수 있도록 더 큰 인스턴스 (최소 m1.large)를 사용해야합니다.