하지만 서비스를 정지시키는 것은 정상적인 컴퓨터 사용을 방해할 수 있고 실제로 실시해봐도 변화가 없었음
본 컴퓨터는 i7-6500U의 컴퓨터였으며, 인텔 i 시리즈 3세대~6세대 컴퓨터에서 윈도우를 AHCI로 설치할 때 문제가 있다는 보고가 간혹 있었다고 함
▶ 해결책
해결책은 윈도우 10의 전원 설정에서 [고성능]으로 된 설정을 만들어 변경해 주면 됨
윈도우 10 설치 후 부팅된 뒤 첫 화면(언어 선택) 컴퓨터가 너무 느려짐을 느꼈다면 [Shift + F10]을 이용하여 CMD에 진입 (이미 윈도우 설치가 끝난 뒤라면 [Windows 키 + R]을 누른 뒤, 실행 창에서 [powercfg.cpl]를 입력하고 3번으로 이동)
(설치 완료 전)
이 장면에서 [Shift + F10]을 누르면 CMD 창이 뜹니다.
(설치 후)
이미 설치 완료한 상태라면 [Windows 키 + R]을 눌러 실행에 진입한 후, powercfg.cpl 을 실행하고 3번으로 넘어갑니다.
2. [ powercfg.cpl ] 을 입력한 뒤 엔터를 쳐 전원 관리 창을 띄운다.
[ powercfg.cpl ] 을 입력하고 엔터를 치면 제어판의 전원 옵션이 뜹니다.
3. 선택 가능한 전원 관리 옵션에 [고성능 (High Performance)]가 이미 있다면 그것을 누릅니다. (이것으로 해결됨, 없다면 4번으로 이동)
이미 [고성능]이 있다면 그것을 클릭하여 해결합니다. 없다면 4번으로 넘어가세요.
4. 고성능이 없다면 왼쪽의 [전원 관리 옵션 만들기]를 눌러 전원 관리 옵션 만들기로 들어갑니다. 들어간 뒤 기존 전원 관리 옵션 중 [고성능]을 누른 뒤, 아래 이름을 임의로 입력(저는 고성능이라고 하였습니다.) 후, 다음을 누릅니다.
기존 전원 관리 옵션 중 [고성능]을 누른 뒤, 이름을 적당히 지어 다음을 누릅니다.
5. 새로 옵션을 만들었다면 [고성능]을 누르면 문제가 해결됩니다.
고성능을 누르는 순간부터 컴퓨터의 속도가 정상으로 돌아옵니다. (다시 균형으로 돌아가면 느림)
작업 관리자에 들어가봐도 이제 디스크 사용률은 0%로 사용할 때만 높아집니다.
▶ 원인 분석
정확한 원인은 알 수 없으나 윈도우 10의 전원 관리 설정과 저장 장치간의 호환성에 문제가 있는 경우에 발생하는 것으로 보임
– WordPress 설정에서 UTC 시각이 표현되야 하는 부분에서 UTC 시각이 아닌 현지 시각이 표시되는 문제가 발견됨
[ 워드프레스 설정에 들어가면 UTC 시각이 이상하게 표시되고 있습니다. ]
– 이는 워드프레스 게시글 발행 시간이 한국 같은 경우에는 9시간 전으로 표시되는 등, 시각 표시가 이상해지는 문제를 발생시켰음
– 서버 시간은 정상적으로 표시되고 있었던 것으로 보아, 문제는 PHP 또는 웹서버에서 나타날 가능성이 높았음
[ 리눅스 콘솔에서 date를 입력하면 정상 시각이 표시되고 있음을 알 수 있습니다. ]
▶ 해결책 모색
– 일단 PHP에서 UTC로 시각을 변환한 다음에 표기하는 소스를 활용하여 테스트를 진행함
<?php
echo "Now Datetime Zone is : <strong>" . date_default_timezone_get() . "</strong><br />";
date_default_timezone_set("UTC");
echo "If right timezone is UTC, your PHP is working great. -- <strong>" . date_default_timezone_get() . "</strong><br />";
echo "Upside zone's time is here -- <strong>" . date('Y-m-d G:i:s') . "</strong><br />";
echo "gmdate()'s result is it -- <strong>" . gmdate('Y-m-d G:i:s') . "</strong>";
?>
– 표시 결과가 UTC로 변경하였음에도 로컬 타임을 UTC로 착각하고 있음 (슬프게도, 한국 시간대인 KST를 평양 시간대로 이해하고 있다. 정말 어이가 없다…ㅠㅠ)
[ UTC 시각이 로컬 시간과 같게 나오는 것을 보니, UTC 타임존이 적용되지 않았음 ]
– 하지만, UTC/GST 시각을 반드시 표기해야 하는 gmdate()는 정상적으로 표시되고 있는 부분이 이상함.
– 결론적으로 PHP 공식 홈페이지에서 확인한 결과, UTC라는 타임존으로 변경하는 것은 앞으로 지양하길 바란다는 메시지를 확인할 수 있었음(여기)
[ 영어는 잼병이므로 자세한 내용은 읽어보시기 바랍니다…ㅠㅠ ]
▶ 해결책
– 일단, date_default_timezone_set(“UTC”); 를 통해 시간존을 바꿀 때는 ‘UTC’라는 표현을 사용하지 않아야 함. (작동하지 않는 경우가 발생하므로)
– UTC 대신, ” Etc/GMT “, 즉 date_default_timezone_set(“Etc/GMT”); 를 사용하면 정상 작동함을 확인할 수 있음
[ 위의 소스코드에서 UTC/GMT 타임존을 해결책 대로 변경한 후의 결과 ]
– 워드프레스의 경우, UTC 시간대를 정해주는 부분이 wordpress 폴더의 wp-settings.php에 위치하고 있으므로, 그 부분의 소스코드를 찾아 다음과 같이 변경할 필요가 있음
// Disable magic quotes at runtime. Magic quotes are added using wpdb later in wp-settings.php.
@ini_set( 'magic_quotes_runtime', 0 );
@ini_set( 'magic_quotes_sybase', 0 );
// WordPress calculates offsets from UTC.
// 여기 부분이 문제입니다! 아래에 있던 UTC를 주석처리한 후, 다음과 같이 변경합니다.
// date_default_timezone_set( 'UTC' );
date_default_timezone_set( 'Etc/GMT' );
// Turn register_globals off.
wp_unregister_GLOBALS();
– 다음과 같이 변경하면, UTC 시각이 정상 표시되어 시각에 문제가 발생하지 않음을 알 수 있음
▶ 원인 분석
– 아마도 PHP5때는 잘 작동하던 것이, PHP7이 되면서 잘 작동하지 않는 것 같음 (분명한 사실은 아님)
– 앞으로 PHP 프로그램에서 이런 문제가 파악될 때는, 대체로 ⓐ서버 시간이 제대로 설정되어 있는지, ⓑPHP 소스 코드에서 UTC로 시각을 변환해주는 부분에 문제가 있는지, 를 파악하면 될 것 같음
– nginx의 HTTP(최근 버전의 nginx에서는 /etc/nginx/sites-available/default 등) 안의 php 소켓 관련 설정에서, 아래와 같은 설정을 추가
server {
(... 중략 ...)
location ~ \.php$ {
# With php7-fpm:
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# 아래부터 버그 해결을 위해 추가해 주실 옵션입니다.
# 502 에러를 없애기 위한 proxy 버퍼 관련 설정입니다.
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
# 502 에러를 없애기 위한 fastcgi 버퍼 관련 설정입니다.
fastcgi_buffering on;
fastcgi_buffer_size 16k;
fastcgi_buffers 16 16k;
# 최대 timeout 설정입니다.
fastcgi_connect_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
# 이 아래 설정은 PHP 성능 향상을 위한 옵션입니다. 추가해 주시면 좋습니다.
sendfile on;
tcp_nopush off;
keepalive_requests 0;
(... 이하 생략 ...)
– 이후 nginx와 php7.0-fpm 을 restart (또는 reload)해주시면 됩니다.
아마 이것으로 대부분의 502 에러는 해결이 됩니다.
$ sudo service nginx restart
$ sudo service php7.0-fpm restart
▶ 해결책 2 : nginx의 설정 파일과 php-fpm 설정 파일의 소켓 일치시키기
– 간혹 nginx의 설정 안에서의 ‘fastcgi-pass’ 경로와, php-fpm 설정 파일의 listen 경로가 다른 경우, 502 Bad gateway 에러가 나타나는 경우가 있다고도 합니다. 이런 경우에는 PHP를 불러오는 대다수의 경우의 에러가 발생하는 경우가 많습니다.
– 먼저 nginx 설정 파일에서 PHP를 처리하는 부분의, fastcgi-pass 값을 확인하여 PHP-fpm sock 파일이 정상적으로 위치해 있는지 확인합니다. (없는 경우에는, sock 파일을 찾아서 적당한 경로로 입력해 주어야 합니다. 많은 경우에는 /var/ 디렉토리 안에서 php 관련 폴더 안에 위치하고 있습니다.)
# nginx 설정 파일 내 PHP 처리 부분(저의 경우는 /etc/nginx/sites-available/default 내)에서,
# location ~ \.php$ { 부분으로 시작하는 곳을 찾습니다.
location ~ \.php$ {
# 안에서,
fastcgi_pass unix:/your/php/sample/php7.0-fpm.sock;
# 부분의 경로에 sock 파일이 있는지 확인합니다.
-------------------------
$ ls -al /your/php/sample/
-rw-r--r-- 1 root root 4 1월 8 12:34 php7.0-fpm.pid
– sock 파일이 있는 것을 확인했다면, PHP-fpm 설정 파일에서 listen 부분의 sock 파일이 경로가 동일한지 확인합니다.
$ sudo nano /etc/php/7.0/fpm/pool.d/www.conf
(PHP 버전 및 설치 방법에 따라 설정파일 경로가 다를 수 있음)
[www]
(중에서, )
; The address on which to accept FastCGI requests.
; Valid syntaxes are:
; 'ip.add.re.ss:port' - to listen on a TCP socket to a specific IPv4 address on
; a specific port;
; '[ip:6:addr:ess]:port' - to listen on a TCP socket to a specific IPv6 address on
; a specific port;
; 'port' - to listen on a TCP socket to all addresses
; (IPv6 and IPv4-mapped) on a specific port;
; '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = /your/php/sample/php7.0-fpm.sock
(listen 부분의 경로가 nginx 설정 파일의 경로와 일치하게 수정)
설정이 끝난 이후, nginx와 php-fpm을 재시작(또는 reload) 해 줍니다.
$ sudo service nginx restart
$ sudo service php7.0-fpm restart
▶ 해결책 3 : php-fpm 설치 후 php-fpm을 실행하지 않은 경우 (…)
– 매우 드문 경우이긴 합니다만, php-fpm 을 설치한 이후 실행하지 않아서 작동하지 않는 경우가 있을 수도 있습니다. (…) service 명령어를 이용해 아래와 같은 명령어들을 실행해 봅니다.
$ sudo service php-fpm start
$ sudo service php5-fpm start
$ sudo service php7.0-fpm start
– 혹은 그저, 프로세스의 문제로 재시작을 하여 문제가 해결되는 경우도 있다고 합니다.
$ sudo service php-fpm restart
$ sudo service php5-fpm restart
$ sudo service php7.0-fpm restart
▶ 끝마치며
nginx와 php-fpm은 간혹 다양한 문제를 내뿜기도 합니다만, 확실히 Apache2 + PHP 조합보다 더 나은 성능과, 복합적인 처리 능력을 자랑하는 만큼, 다양한 에러를 해결해 나가면서 점점 nginx가 최적화 될 수 있도록 설정하실 수 있으실 것이라고 확신합니다.
502 Bad gateway 또한 다양한 이유에 의해 문제가 발생하고 있기도 하고, 또 다양한 방법으로 해결되기도 합니다. 그런 만큼, 포기하지 마시고 해결하실 수 있으시면 좋겠습니다.
오늘은 Creative Suite(이하 CS)로 같이 설치한 Acrobat X가 정품 인증이 제대로 되어 있음에도 시간이 흘러서 (공식 홈페이지의 설명에 따르면 30일 이후) 실행되지 않을 때의 문제 해결 방법에 대해 살펴보고자 합니다.
▶ 증상이 시작된 원인
– Adobe CS6(Creative Suite, 크리에이티브 스위트) 에서 같이 설치되는 Acrobat X(아크로벳 X, 아크로벳 10)을 설치했을 때는 잘 실행되었었음
– 문제는 며칠 지나고 나니, Acrobat X가 실행이 되지를 않음
– 유일하게 변화했던 것은 시간이 지났다는 것 뿐이었음
▶ 구체적 증상
– Acrobat X가 시간이 지나서 실행이 되질 않음 – PDF 파일을 실행해도 실행되지 않음
[ PDF 파일을 눌러도 반응이 없고… ]
– Acrobat X 아이콘을 눌러서 실행해도 실행이 되질 않음
[ 아무리 Acrobat X Pro를 실행해도 실행도 안되고… ]
▶ 해결책
– 결론부터 말씀드리면, 이것은 여러분들의 실수 또는 설치가 잘못된 것이 아닙니다.
– Adobe 공식 홈페이지의 서포트 센터를 살펴본 결과, 이러한 증상이 일부 컴퓨터에서 CS6 합본으로 설치했을 때 나타나는 것을 확인했습니다.
– 따라서 아래 Adobe 공식 서포트 센터에서 Acrofix.zip을 다운받아, 그 안의 실행 파일을 실행합니다.
※ Acrobat 도움말 / 30일 이후 실행되지 않음 | CS6 스위트와 같이 설치되었을 때 (ENGLISH Site, Acrobat Help / Doesn’t launch after 30 days | Installed as part of a CS6 suite)
– Acrofix.zip 안에 있는 실행 파일을 실행하고 나서 Acrobat을 실행하면, 바로 Acrobat X가 정상적으로 작동하는 것을 확인할 수 있습니다.
[ 이와 같이 Acrobat X가 잘 실행되게 되었습니다. : ) ]
▶ 문제점 (예상)
– 이 문제는 다른 Suite 프로그램을 통해 정품 인증을 받았으나, 그것이 Acrobat X와 연동 되는 중 발생하는 버그로 보입니다.
– 따라서, 이런 문제가 발생했을 때 다른 Suite 프로그램에서 정품 인증을 다시 받을 때 해결이 될 수 있다고도 합니다. 혹시 Windows 이외의 플랫폼에서 이런 문제가 발생한 경우, 또는 위의 해결책으로 해결이 안되거나 하는 경우에는 아래의 해결책으로 문제 해결을 시도해 보십시오.
1. CS6 Suite 제품을 실행합니다. (Acrobat X 이외)
2. Help(도움말) > Deactivate(인증 해제)를 선택해, 인증 해제를 위해 절차를 진행해 주십시오.
3. 어플리케이션을 종료합니다.
4. 방금 정품 인증을 해제한 CS6 Suite 어플리케이션을 다시 실행합니다.
5. EULA(최종 사용자 조약)에 동의합니다.
6. 당신의 Adobe ID를 활용하여 체험판 사용을 활성화 합니다.
7. 어플리케이션을 종료하고 다시 실행합니다.
8. 체험판 설명 화면에서 소프트웨어 라이센스 인증을 클릭합니다.
9. 등록을 위해 당신의 Adobe ID로 로그인합니다.
10. CS6 시리얼 넘버를 등록합니다.
11. 다음을 누릅니다.
12. 어플리케이션을 종료합니다.
13. Acrobat X를 실행합니다.
오늘은 크롬 등의 브라우저에서 네이버 페이지 등(필자는 네이버 페이지였으나 다른 페이지도 이럴 수 있음)이 하얀 화면으로만 나오고 아무 화면이 나오지 않는 경우의 해결 방법에 대해 알아보고자 합니다.
▶ 증상이 시작된 원인
– Windows 10을 설치한 이후, 크롬 브라우저(버전 46) 에서 네이버 페이지(메인 페이지만, 검색 결과 페이지는 잘 열리는 것을 확인함)가 하얀 화면으로 열리지 않는 증상을 확인
– 필자가 윈도우 10을 설치한 것은 오래 되지 않았으므로, hosts 파일 등의 위조는 없었고, 실제 확인 결과로도 hosts 파일이 변조되어 일어난 증상은 아닌 것을 확인
(hosts 파일이란 여러분들이 도메인을 접속하고자 할 때 특정 IP로 접속되게 할 수 있는 컴퓨터의 통신 정의 파일입니다. hosts 파일의 변조에 대해서는 다른 블로그에 검색하면 많은 해결책이 제시되어 있을 것입니다.)
– 백신은 Avira Antivirus Pro를 사용하고 있었고, 이것이 문제가 되었음
▶ 구체적 증상
– 다른 페이지의 인터넷은 다 잘 접속이 되고, 통상적인 통신에는 문제가 없으나, 특정 페이지가 접속 되어도 하얀 화면으로 보이는 증상을 보임
– 필자는 크롬 브라우저에서 네이버 메인 페이지로 접속이 되지 않았음
[ 위와 같이 하얀 네이버 화면과 마주하게 되었다 (…) ]
▶ 해결책
– Avira Antivirus Pro에는 “Web Protection” 이라는 기능이 있는데, 이 기능은 문제가 될 수 있는 사이트에 접속할 시 자동으로 페이지 접속을 차단하는 것으로 보임
– 하지만 네이버 메인 페이지가 Web Protection에 의해서 필터링 되는 문제가 생김
– 다만 네이버 페이지와 같은 곳에는 접속을 허용할 수 있도록 하는 예외를 만드는 방법은 없기 때문에, 다음과 같이 Web Protection 기능을 Avira에서 지워줄 필요가 있음
[ 윈도우 10부터는 검색에서 제어판에 접근할 수 있다. ]* 검색 창이 없을 경우, 시작 버튼을 누르고 ‘제어판’을 검색하면 됩니다.
[ 제어판에서 프로그램 및 기능에 들어가 Avira Antivirus를 찾아 변경을 누른다. ]
* Avira Antivirus를 누른 뒤, ‘변경’을 눌러 Modify를 실행합니다.
[ Web Protection 기능에 체크를 해제하고 다음을 눌러 설치를 마무리 합니다. ]
– 문제가 해결되면 다음과 같이 네이버가 정상적으로 접속됩니다.
[ 네이버 페이지에서 정상적으로 접속되는 것을 확인할 수 있다. ]
▶ 문제점 (예상)
– Avira Antivirus Pro의 버그로 보이고, 실제로 어떤 것이 문제가 되는지 파악하기 어려운 면이 있었음
– 네이버 메인페이지가 Internet Explorer에 최적화 되어 있는 코드를 가지고 있기 때문에 나타나는 문제가 아닐까 하는 생각도 듦
– 참고로 스윙브라우저 등의 경우에도 문제가 발생하는 것으로 보여, 아래 글을 참조하면 도움이 될 것 같음
– ASRock H61M/U3S3 메인보드를 사용하는 컴퓨터의 모든 장치 드라이버를 설치했음에도 불구하고 알 수 없는 장치가 남아있는 경우
– 필자는 메인보드 홈페이지에서 메인보드 드라이버를 다운받는 것을 원칙으로 하되, 칩셋 드라이버 등은 최신 버전의 다운로드를 위해 인텔 홈페이지에서 다운받는 등 드라이버를 제멋대로 받았었음
[ 이렇게 알 수 없는 장치로 장치 관리자에 나타납니다. ]
▶ 구체적 증상
– 장치 관리자에 들어가니 모든 드라이버는 잘 잡혀있는데 [기타 장치 > 알 수 없는 장치]로 설치되지 않은 장치가 한개 나타났음
[ 하드웨어 ID가 같은 경우, 같은 증상일 확률이 거의 100%입니다. ]– 클릭해보면 위치는 Microsoft ACPI-Compliant System로 나타나고, 자세히를 눌렀을 때 하드웨어 아이디가 아래와 같이 나타남
ACPI\INT33A0
*INT33A0
▶ 해결책
– 결론부터 이야기하면, Intel Smart Connect 드라이버가 설치되지 않았기 때문으로, 메인보드 제조사에서 올바른 드라이버를 설치하던지, Intel 홈페이지에서 칩셋에 맞는 스마트 커넥트 드라이버 설치가 필요함
[ 각사 드라이버 홈페이지를 찾아보시면, Intel Smart Connect Driver를 찾으실 수 있습니다. ]– 필자는 ASRock H61M/U3S3을 사용중이므로, 해당 제품 제조사 메인보드 드라이버 제공 홈페이지에서 Smart Connect 드라이버를 다운받아 설치해 해결
– 설치가 끝나면, Intel(R) Smart Connect Technology Device라고 시스템 장치에 정상적으로 드라이버가 잡히는 것을 확인할 수 있음
[ 성공적으로 드라이버가 인식되었습니다. ]
▶ 문제점 (예상)
– Intel Smart Connect Technology (인텔 스마트 커넥트 기술) 이란, 노트북 등의 컴퓨터 제품에서 절전 모드에 들어가 있을 때에도 프로그램이 통신을 주고 받을 수 있도록 제공되는 기술임
[ ASRock의 스마트 커넥트 지원 유틸리티 ]– 스마트 커넥트 드라이버가 설치되어 있고, 각 메인보드 제조사에서 제공하는 스마트 커넥트 프로그램을 활용하면, 대기 모드에서도 메일을 다운로드하거나 하는 것이 가능하게 됨
(자세한 사항은 인텔 스마트 커넥트 설명 홈페이지를 참조 요망)
[ 출처 : Intel 공식 홈페이지 ]
– 좀 더 검색해보니, Z68, H67, H61 계열의 칩셋 메인보드 제품에서 스마트 커넥트 드라이버가 추가될 수 있다고 합니다.
(관련글 참조)
– 편한 드라이버 다운로드를 위해 아래 몇몇 메인보드 회사의 드라이버 서포트 페이지를 참조하세요.
– 발견된 증상은 없으나 결론적으로 미디어의 문제였기 때문에 다양한 측면에서 문제가 발생할 수 있음 (다만 업데이트가 되지 않는 증상은 동일할 것 같은데, 업데이트 프로그램에서 가지고 있는 원본 데이터와 컴퓨터에 설치된 프로그램이 다른 것으로 파악될 것으로 생각되기 때문)