윈디하나의 블로그
윈디하나의 누리사랑방. 이런 저런 얘기
16 개 검색됨 : 기술,IT/서버 에 대한 결과
- 글쓴시간
- 분류 기술,IT/서버
May 8 21:07:59 wl gda: [ID 107833 kern.warning] WARNING: /pci@0,0/pci-ide@1f,2/ide@1/cmdk@1,0 (Disk1):
May 8 21:07:59 wl Error for command 'read sector' Error Level: Retryable
May 8 21:07:59 wl gda: [ID 107833 kern.notice] Sense Key: ICRC error during UDMA
May 8 21:07:59 wl gda: [ID 107833 kern.notice] Vendor 'Gen-ATA ' error code: 0x16
ICRC: ATAPI 장치(예를 들어 SATA 방식의 HDD)에서 UDMA 를 사용시 ICRC(Interface CRC) 비트를 사용함 기본적으로 "전송 오류"
0x16 은 뭔가 응답이 오지 않은 경우에 해당되는듯. 재시도 가능.
일반적으로 "read sector" 커맨드에 대한 오류는 HDD 배드섹터에 기인하긴 하지만, 이 경우는 좀 아리송하다. 약 7시간 동안 45번 나고 더 이상 오류가 발생하지 않았음. 뭐징. OS 패치를 대량으로 하면 안보이던 오류가 많히 보인다. 일단 백업을 자주하는걸로 결정.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
블로그를 백업본으로 복구했다. 갑자기 아래와 같은 로그를 내면서 MySQL 이 죽어서 그렇다.
2022-04-20T09:00:24.015047Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4554ms to flush 164 and evict 0 pages
17:00:26 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x2b42e148
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7fffbf04df10 thread_stack 0x46000
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19my_print_stacktracePKhm+0x2e [0x385a3ee]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_fatal_signal+0x2f7 [0x26a6cb7]
/lib/amd64/libc.so.1'__sighndlr+0x6 [0x7fffbe14ebe6]
/lib/amd64/libc.so.1'call_user_handler+0x2f1 [0x7fffbe1406b1]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z27free_blob_buffers_and_resetP5TABLEj+0x77 [0x2658077]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z18close_thread_tableP3THDPP5TABLE+0xdc [0x24b192c]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19close_thread_tablesP3THD+0x28b [0x24b1c1b]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_ZN18Prepared_statement7prepareEPKcmPP10Item_param+0x881 [0x25807f1]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19mysqld_stmt_prepareP3THDPKcjP18Prepared_statement+0xb6 [0x2581016]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x2097 [0x2556917]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z10do_commandP3THD+0x174 [0x2557344]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_connection+0x278 [0x2698468]
/usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'pfs_spawn_thread+0x161 [0x3d8e4b1]
/lib/amd64/libc.so.1'_thrp_setup+0xa4 [0x7fffbe14e7e4]
/lib/amd64/libc.so.1'_lwp_start+0x0 [0x7fffbe14eac0]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (2b436af0): SHOW TABLES LIKE 'piwik_archive_numeric%'
Connection ID (thread ID): 1903317
Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
-이후 재시작하면
2022-04-21T00:10:10.515295Z 1 [Note] [MY-011089] [Server] Data dictionary restarting version '80023'.
2022-04-21T00:10:10.869298Z 1 [Note] [MY-012357] [InnoDB] Reading DD tablespace files
2022-04-21T00:10:10.914548Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2022-04-21T00:10:10.915345Z 0 [ERROR] [MY-010119] [Server] Aborting
2022-04-21T00:10:10.916445Z 0 [Note] [MY-010120] [Server] Binlog end
2022-04-21T00:10:10.916763Z 0 [Note] [MY-010733] [Server] Shutting down plugin 'MyISAM'
2022-04-21T00:10:10.916890Z 0 [Note] [MY-010733] [Server] Shutting down plugin 'InnoDB'
2022-04-21T00:10:10.917046Z 0 [Note] [MY-013072] [InnoDB] Starting shutdown...
바로 종료됨.
- 구글링도 해봤지만 흔한 에러는 아닌듯 하다. 메시지만 보면 Data Dictionary 를 초기화하다가 오류. 그렇다면 mysql.ibd 파일에 문제가 있다는 거긴 하지만, MySQL 지원을 받을 수 있는건 아니라 포기. 만약 업체였다면 비용 들여서라도 지원받으면 되지 않을까 하는 생각이다. 예전에 5.x 버전에서 8 로 업그레이드가 제대로 안된것 같기도 하다.
- 처음에 난 덤프도 DataDictionary 를 조회하다가 오류난 것이기도 하다. 결국은 복구 불가로 판정했고 바로 백업본을 리스토어 했다. 이래서 백업은 중요하다. 매우 중요하다.
- 어쨌든 복구하느라고 MySQL 8을 재설치하고 백업본을 복구한거기 때문에, 서버가 꽤 빨라졌다. my.cnf 파일도 처음부터 재작성했다. 어쨌든 괜찮아진 느낌.
----
2022.04.26 추가
MySQL 8을 작년에 설치한것도 MySQL 5.x 에서 업그레이드한거였는데, 지금 생각해보면 뭔가 업그레이드가 잘못되었을 거 같다. my.cnf 에 문제가 있었는데도 작동했기 때문. MySQL 8 설치하고 첫 실행했을때 기동이 안되었다. my.cnf 를 초기화(내용을 전부 지움)하면 기동이 되었고. 뭔가 설정에 문제가 있긴 했던 느낌.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
ZombieLoad(Microarchitectural Data Sampling)
예측실행(Speculative execution) 를 데이터를 읽어올 수 있는 보안문제가 발견되었네요. 2019년 5월에 발견된거니 꽤 최근의 일입니다. 에혀.
예전에 CPU의 예측실행, 예측분기, 비순차적실행 기능을 추가해서 성능을 향상시켰는데, 이게 되려 보안적으로는 발목을 잡나보네요. 어직 Meltdown, Spectre 도 제대로 해결이 안되었는데요.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
Foreshadow 취약점 (L1 Terminal Fault)
Intel 의 SGX (Software Guard Extensions) 를 이용해 L1 캐시상의 데이터를 읽을 수 있는 문제가 발견되었네요. 2018.08 에 보고되었습니다. OOE (Out-of-Order Execution) 를 이용하고 Side Effect 를 사용해 읽어냅니다. 어떻게 보면 Meltdown 나 Spectre 와 비슷합니다. 이거 L1 캐시의 보안성에 의문이 생기네요. 아예 구조를 바꾸지 않는 이상 계속 발견될 것 같은 느낌이네요. 머 L1 캐시를 임의로 읽을 수 있으면 말 다한거죠.
보안전문가들 사이에서는 Foreshadow, 인텔은 L1TF(L1 Terminal Fault)이라 불립니다. Fault (=결함)이라는 거죠.
그나마 다행인건 상당히 공격하기 어렵다고 하네요.
이후 Foreshadow-NG 가 발견되었습니다. SGX 를 사용하지 않는 결함으로, Core2 부터 Core 8세대까지 영향을 받습니다. 참고로 SGX는 Skylake 부터 적용되었으니 Core 6세대 부터입니다.
구체적으로 언제인지는 모르겠습니다만, 2021년의 마이크로 코드 업데이트로 수정했습니다. 취약점을 수정하면 속도가 다소 느려집니다.
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html
그나마 다행인건 상당히 공격하기 어렵다고 하네요.
이후 Foreshadow-NG 가 발견되었습니다. SGX 를 사용하지 않는 결함으로, Core2 부터 Core 8세대까지 영향을 받습니다. 참고로 SGX는 Skylake 부터 적용되었으니 Core 6세대 부터입니다.
구체적으로 언제인지는 모르겠습니다만, 2021년의 마이크로 코드 업데이트로 수정했습니다. 취약점을 수정하면 속도가 다소 느려집니다.
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
Row Hammer, RAMBleed
잘 모르고 지나갔습니다만, 이런 문제가 있었네요. "Row Hammer" 취약점은 특정 메모리영역의 데이터를 임의로 변경할 수 있는 취약점이고, RAMBleed 취약점은 특정 메모리 영역의 데이터를 읽을 수 있는 취약점입니다.
DDR3 메모리에 대해 Row Hammer 취약점이 발견되어서, DDR4 의 개발에도 영향을 미쳤다고 하는데요, DDR4 에도 Row Hammer 의 변형된 공격에는 취약하다고 합니다. 이 기능은 메모리의 ECC 기능에 의해 무력화될 수 있다고 생각되었습니다만, 최근에는 이것도 무력화시킨다고 하네요. 해결방안은 메모리 암호화 뿐이라고 합니다. 최신 CPU 에서나 지원 되고 활성화 되며 OS 에서도 이제야 쓸까 말까 하는 기능입니다.
RAMBleed 는 Row Hammer 를 응용해서 Site Effect 로 특정 메모리의 값을 유추해낼 수 있는 취약점입니다. 어떻게 보면 HeartBleed 와 비슷하네요.
메모리의 구조상 하나의 ROW 로 여러개의 데이터 비트를 관리하게 되는데요, Row Hammer, RAMBleed 는 이걸 이용한다고 하네요. http://windy.luru.net/1074 에 간단하게 언급되어있습니다.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
시게이트의 고성능 데스크탑용 디스크인 BarraCuda Pro
※ 하드디스크(HDD)를 고르다보면 데스크톱용, 노트북용, 서버용(NAS, 감시, 엔터프라이즈) 등등 용도에 따라 여러가지로 나뉘어 있는걸 알 수 있다. 각각의 용도에 따라 다른점은 아래와 같다.
- 가격대를 보면 엔터프라이즈용이 가장 비싸고, 감시나 NAS 용 하드디스크 역시 고가에 형성되어있다. 데스크톱용이 가장 싸다.
- 크기로만 보면 데스크톱과 서버용이 3.5인치 규격(101.6 mm × 25.4 mm × 146 mm)이고, 노트북용이 2.5 인치 규격(69.85 mm × 7~15 mm × 100 mm)을 사용한다.
- HDD 는 플래터라는 회전하는 금속 원반 위를, 헤드가 움직여서 자기력을 이용해 금속 원반 상의 한 점의 극성을 변경하면서 데이터를 쓴다. 읽는건 헤드를 움직여 금속원반의 극성을 알아내는 방식이다. 플래터와 헤드는 접촉되어있지 않다.
- 금속 원반을 회전시키기 위해 모터가 장치되어있고 이 "모터"때문에 HDD가 PC안의 다른 전자기기와는 다른 기계적인 특성을 가진다.
- 성능은 서버용 하드디스크 중에 엔터프라이즈용이 가장 좋고 데스크톱용, 노트북용 순이다. 감시용은 성능이 낮다.
※ 좀더 기술적인 이야기를 하자면 아래와 같은 차이점이 있다.
- 첫번째는 진동과 충격에 대한 대비가 다르다. 기본적으로 5400 ~ 7200RPM, 엔트프라이즈급은 10000RPM 이 넘기 때문에, 이정도로 고속 회전하는 금속원반을 잘 잡아서 진동이 덜 일어나게 하는 것이 매우 중요하다. 데스크탑용은 플래터가 HDD하단에 마운트되어있고 NAS용이나 엔터프라이즈급은 하단과 상부에 각각 붙어있다. 따라서 서버용이 더 안정적이다. 서버용은 좁은 공간에 하드디스크를 수십/수백개를 달아놓기 때문에 서로서로 진동을 발생시키고 이게 각각의 HDD에 영향을 받기 때문에 진동을 발생하지 않도록 하고 발생되어도 HDD를 보호하기 위한 장치가 잘 되어있다. 또한 사람이 손으로 툭 치는 정도의 충격도 하드디스크에 그대로 전달되면 하드디스크 망가진다. 그래서 기본적인 충격 보호 장치는 모든 HDD에 달려있지만, 서버용은 이걸 더 정교하게 장치했다. 충격 센서까지 달려있다.
- 두번째는 읽기/쓰기 알고리즘이 다르다. 예를 들어 CCTV는 순차적인 쓰기가 가장 많이 발생하기 때문에 이에 대한 최적화가 되어있다.
- 세번째는 전원 관리 알고리즘이 다르다. 데스크탑이나 노트북의 경우 유휴기간에는 전원을 끄지만, 서버급은 유휴기간에는 RPM을 줄여 전력소비를 줄인다. CCTV용은 페쇄된 외부환경에 노출되기 때문에 저발열, 저전력에 특화되어있다.
- 네번째는 이동성이 다르다. 노트북용 HDD는 휴대를 전제로 하기 때문에 가장 충격에 대한 대비가 잘되어있다.
- 다섯번째는 수명이 다르다. 워크로드(WorkLoad)라 부르는데 읽고 쓸 수 있는 용량의 기준이 데스크탑용과 서버용이 배이상 차이난다.
--> 쉽게 말하자면 HDD 는 정말정말 용도에 맞게 써야 된다는 거다. 비싸다고 싼거 쓰지 말자.
※ 원래 데스크탑-노트북용과 서버용으로 나뉘어있던게 서버용이 좀 더 세분화되었다.
-> 용도가 분류되어있는 하드디스크에서, 서로 같은건 플래터와 헤드뿐이다. 나머지를 구성하고 있는 부품은 모두 다르다. 필자는 충분히 비용을 지불할만한 가치가 있다고 생각한다. NAS 장비에 엔터프라이즈급 HDD를 쓰는게 좋지만, 비용이 문제라면 NAS용 HDD라도 쓰자.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
TLS 1.3이 발표되었습니다. 발표된지는 꽤 되었는데, 제 사이트에서 적용시킨 다음에 이 내용을 쓰려고 좀 기다렸네요.
TLS 1.3 으로 접속된 windy.luru.net
TLS 1.3 의 주요 특징은 아래와 같습니다.
- 더 빨라짐: 핸드쉐이크를 개선해서 기존대비 더 빨라졌습니다. TLS 1.2 에서는 서버와 클라이언트 간에 6번 왔다 가야 하는데 반해, TLS 1.3에서는 4번으로 줄었습니다. 그래서 1/3만큼 빨라질걸로 예상합니다.
- 보안성 향상: 더 향상된 암호화 알고리즘(ChaCha20, Poly1305, Ed25519, x25519)을 사용할 수 있게 됩니다. 또한 기존에 취약했던 암호화 알고리즘을 더이상 사용하지 않도록 했습니다.
2018년 10월 이후 릴리즈 되는 브라우저들은 (즉 현재 최신 브라우저들은) TLS 1.3을 공식 지원합니다. Chrome 70, Firefox 63부터입니다. 하지만 Chrome 70은 기본값으로 사용하지는 않습니다. 아직 Edge 는 지원 안하는데 조만간 지원할걸로 예상합니다.
Chrome TLS 1.3 세팅. chrome://flags 에서 TLS1.3 세팅을 Enabled(Final)으로 변경해야 한다.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
※ 어느날 갑자기 svchost.exe 라는 프로세스가 코어 1개를 100% 차지하면서 시스템 전체 CPU 사용량이 늘어나고 PC가 느려지는 현상이 발생했다. 그래서 살펴본 결과 wuauserv 서비스의 소행인걸 알아냈다.
※ wuauserv 는 "윈도 업데이트" 서비스다. 원래 가끔씩 CPU를 많이 차지하면서 뭔가가 실행되고 디스크를 많이 읽는 현상은 당연한거다. 하지만 필자의 경우는 수시간째 계속 그랬다.
작업관리자 상황. 오른쪽 아래의 "리소스 모니터"를 클릭해 리소스 모니터를 실행하자.
※ 당장 느려지는게 문제라면 해당 서비스를 정지시키면 된다. 리소스 모니터에서 wuauserv를 선택하고 오른쪽 버튼을 눌러 "서비스 중지"를 클릭하면 된다.
리소스 모니터에서 wuauserv 를 찾았다.
※ 근본적으로 해결하려면 패치를 하면 된다.
https://support.microsoft.com/en-us/kb/3172605 에서 "Windows6.1-KB3172605-x64.msu" 파일(윈도7 x64기준)을 다운받아 업데이트하면 된다.
※ 아예 윈도 10으로 업그레이드 해도 되지만 wuauserv 때문에 업그레이드가 많이 느릴 것이다. 업그레이드 전에 패치를 먼저 하자.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
별 생각없이 서버들어가서 uptime 이라는 명령을 쳐보았다.
두둥
2091 일이라니. 뭔가 잘못되었다. 아마 이 서버의 uptime 은 30일 조금 안될꺼다. 근데 이게 왜 바뀐건지는 잘 모르겠음. 버그인감.
참고로 uptime 이란건 어떤 장치의 운영 시간, 작동 시간을 말한다. 주로 컴퓨터의 이야기. 즉 "업타임이 2091일"이라는건 컴퓨터를 켜고 운영체제로 부팅 한 후, 5.7년동안 한번도 안 껐다는 의미다. Uptime 은 틱카운트를 세기 때문에 수정/조작 하는게 불가능한걸로 아는데, 내가 모르는 뭔가가 더 있는건감.
서버 관리 처음할떄에는 왠지 업타임에 신경썼었다. 가급적 안끄는게 좋은건 맞으니깐. 실제 서비스 중인 서버로 1800일은 넘겨봤다. 약 5년동안 한번도 안 껐다는 이야기. 엔터프라이즈급 솔라리스 서버였는데, 꺼야할 일이 없었다. 서버도 굉장히 안정적으로 돌아가고. 어쩔 수 없이 끈건 이중화되어있는 스토리지 컨트롤러중 한쪽 노드에 장애가 발생해 결국 하드웨어를 교체해야 했기 때문이다. PnP 지원되긴 했지만 만약을 위해 껐다 켰다.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/서버
- 2015.02.17에 HTTP/2 프로토콜이 승인되었습니다. RFC 등록이 남아있긴 하지만 이건 시간문제일 뿐이구요.
- HTTP란 웹의 근간을 이루는 프로토콜의 이름입니다. 웹 주소(예를 들어 http://windy.luru.net) 첫머리에 나오는 http 가 바로 그겁니다.
- 이번 HTTP/2 프로토콜은 현재 사용하고 있는 HTT/1.1 의 뒤를 잇는 프로토콜입니다. 1999년 발표된 프로토콜로 오래되긴 했지만 큰 문제 없이 쓰다가, 어느 시점부터 성능에 대한 불만이 생기기 시작합니다. 특히 https 가 대중화 되면서 더욱 가중되었죠. 뭔가를 바꾸면 훨씬 빨라질 수 있는데 그걸 표준 규격 지키느라고 못바꾸니까요.
- 답답해하던 구글은 결국 SPDY라는 프로토콜을 제안합니다. SPDY는 몇차례의 개정을 거치다가 SPDY 4.0 즉 HTTP/2 로 결실을 보게된겁니다.
- HTTP/2 의 핵심은 '다중화'입니다. '요청-응답-요청-응답'의 순서를 반드시 지켜야 할 필요 없게 된거죠. 이렇게 되면 서버에서 'I/O다중화'를 적극적으로 사용해 괄목할만한 성능 향상을 이뤄낼 수 있게 됩니다. 성능 향상정도는 특히 https 에서 두드러집니다.
- 현재 Chrome 40과 Firefox 36에서 HTTP/2를 지원하고 있습니다. 곧 나올 Windows 10의 IE11과 IIS에서도 지원됩니다. 문제는 오픈소스 웹 서버들인데 Nginx, Apache, lighttpd 가 지원을 못합니다. 특히 가장 널리 사용되는 서버인 아파치가 아직 지원을 못하기 때문에 범용적으로 사용하질 못하고 있습니다. 물론 이런 브라우저들도 지원계획은 있는데 아직 구현하지 못한것일 뿐 지원은 당연한 사항입니다. 어서빨리 지원되었으면 좋겠네요.
----
2015.10.13 업데이트
Apache 2.4.17 부터 mod_http2 를 통해서 http2 지원하네요. libnghttp2 를 사용하기 때문에 같이 설치해줘야 합니다.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음