Learn Everywhere

top을 일상적으로 사용하진 않아서 필요시에 찾아보면서 사용중인데 정리가 잘 된 글이 있어 가져와 봤다. 출처 :  https://sabarada.tistory.com/146 안녕하세요. 오늘은 linux의 top 명령어어 대해서 분석하는시간을 가져보도록 하겠습니다. TOP 명령어 top 명령어는 현재 OS의 상태를 나타내주는 CLI 어플리케이션 입니다. 메모리 사용량, CPU 사용량 등을 나타내주며 top를 실행하는 동안에는 주기적인 업데이트로 실시간에 근접한 내용을 보여줍니다. 리눅스에서 top 명령어를 실행하면 아래와 깉이 노출됩니다. 위에는 전체의 요약이 있으며 아래에는 각 프로세스마다 구체적인 내용을 포함하고 있습니다. 요약 영역 요약 영역은 top에서 상단에 위치하고 있습니다. 이  요약영역은 전체 프로세스가 OS에 대해서 리소스를 어느정도 차지하고 있는지 를 알려줍니다. 요약 영역에 나타나는 대표적인 값은 시간, 유저, 로드 에버리지(Load Average), 테스크(Tasks), CPU, 메모리(memory)로 아래의 이미지를 보시면 각 영역에 대해 나태내느 값이 어디에 위치하는지 알 수 있습니다. 시스템 현재 시간, OS가 살아있는 시간, 유저 세션수(System time, uptime and user sessions) 이미지의 가장 왼쪽 위를 보시면 시스템 현재 시간, OS가 살아있는 시간, 그리고 유저의 세션수가 표시되는 영역이 있습니다.  가장 먼저 보이는 숫자가 시스템의 현재 시간 입니다. 이 시간은 GMT 기준으로 표시됩니다. 위 예제 기준으로 GMT 16:58:55 이라는 것입니다. 이것은 한국시간으로 보면 +9를 한 00시 58분 55초와 동일합니다.  다음으로 표시되는 것이 OS가 얼마나 살아있는지 나타냅니다.  days와 시간으로 표시되며 위 예제로보면 7일과 1시 15분 동안 서버가 살아있었다는 것을 알 수 있습니다.  그리고 다음 나타나는것이 현재 접속중인 유저 세션 수 입니다. 좀 더 자세한 유저세션이 궁금하다면  who

retry 관련 같은 문제를 격고 있었는데 아래 출처의 내용이 도움이 되었다.  그래서 개인 기록용으로 출처 내용 가져다 놓았다. 출처 :  https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=bitofsky&logNo=221071064114   Socket.io에서 여러개의 인스턴스를 redis pub/sub으로 묶어 broadcast할 때 socket.io-redis를 사용하게 되는데요. 주의사항이 있습니다. 만약 redis가 죽는 경우나 connection에 문제가 생기는 경우를 대비해 redis에는 retry_strategy 옵션이 존재합니다. 헌데, socket.io-redis를 사용하는 경우 retry_strategy가 동작하지 않고 Node 프로세스가 uncaughtException을 받고 죽어버리게 됩니다. (WTF?) socket.io-redis에 이를 핸들링할 수 있는 에러 핸들러 같은걸 제공하지 않기 때문에 이 상황을 막으려면 다음과 같이 Adapter 연결시에 직접 event emiter에 셋팅을 해야합니다. (WTF??) const io = require ( ' socket . io ' )( server ); io . on ( ' connection ' , socketConnected ); io . on ( ' error ' , err => console . error ( ' Socket . IO Error ' , err )); const redis = require ( ' redis ' ); const pub = redis . createClient ( pubClient . port , pubClient . host , pubClient ); const sub = redis . createClient ( subClient . p

JPA Entity @Id 필드값으로 DB 체번을 하지 않고 수동 입력으로 설정 해야 할 경우가 있다. 이때, 데이터 저장을 위해 save()를 호출해 보면, select가 먼저 실행 되고 insert가 실행 되는 것을 볼 수 있다. 간략히 이유를 설명하자면, id가 null 일때는 pk가 없는 것과 동일하기 때문에 entity manager는 새로운 데이터로 간주할 수 있으므로 바로 insert를 실행 한다. 그러나 id가 있으면 DB에 이미 존재하는 데이터 일 수 있으므로 먼저 찾아보고 없으면 insert를 하기 때문이다. select가 없이 insert를 실행하고자 하면 아래와 같이 해당 entity에서 Persistable을 구현해 주면 된다. @Entity @Table ( name = "my_table" ) public class MyTable implements Persistable < String > { @Id @Column ( name = "id" ) private String id ; @Transient private boolean isNew = true ; @Override public boolean isNew () { return isNew ; } @Override public String getId () { return this . id ; } @PrePersist @PostLoad void markNotNew () { this . isNew = false ; } ... } 다른 부분들은 제외하고 필요한 부분만 넣었고 설명을 추가하자면, Persistable 인터페이스의 isNew()와 getId()를 구현해 주어야 한다 isNew