넥서스7 2세대 충전단자 문제 ASUS AS센터 방문

넥서스7 2세대 사용 1년 반만에 충전단자 고장. ASUS에서 AS를 처리하고 있습니다..
무상 AS 기간은 1년이고, 구매 영수증이 있는경우 구매한 날로 1년이고 없는경우 시리얼 조회해서 1년 기간으로 무상 처리 됩니다.

충전단자 고장으로 AS센터를 방문했던 후기나, 비용을 찾아보려 했지만 사설 AS 업체의 블로그만 나와서 직접 용산에 있는 AS센터 방문했습니다.

결과적으로 충전단자 교체 비용은 3만원 이고 시스템은 초기화 됩니다.

AS방문전에 중요한 자료는 필히 백업받으셔야 합니다. 대기자 수에 따라대기 시간이 변동되기는 하지만 수리시간은 20~30분 정도 걸린거 같습니다.

참고로 용산 ASUS 서비스센터 지도 첨부합니다.



구글지도로 보기

editplus ftp 접속 오류

원격 디렉토리를 변경할 수 없습니다. 타입에 해당하는 데이터 레코드가 없습니다.editplus FTP설정 후 접속시 나오는 오류 입니다.

원인은 이메일이나 다른 웹에디터 등으로 도메인, 계정, 비번등을 전달 받고 마우스로 드레그 하는 과정에서 다른 인코딩된 문자열이 같이 복사되는 경우 였습니다.

해결 방법은 전달받은 계정정보를 긁어 복사하지 말고 키보드로 정확하게 키보드로 입력하면 접속됩니다.

저같은 경우는 다음 이메일로 전달받은 계정을 복사하면서 다른 인코딩 문자열이 포함된 경우 입니다.

웹사이트 로딩속도 향상 시키기

가벼운 웹사이트 만들기


구체적이지는 않지만 잘 정리된 블로그다.
물론 전부 적용하면 빠르겠지만, 해보면 알겠지만 유지보수에 손이 많이 간다.

예를 들어..
이미지 스프라이트의 경우 이미지가 추가 될때마다 CSS가 추가된다.
브라우저캐싱을 활용하면 이미지,css,js파일등이 변경될때마다 주소값이 변경되어야 한다.
css,js 압축시 수정사항이발생될때마다 압축하는 작업이 필요한다.
등등등... 물론 수고한 만큼 성능으로 돌아온다. ^^;


수정되어야 할 부분이 있다면 SNS공유 버튼은 사이즈가 크고 페이지 내용을 모두 보여지기 전에 로드가 되니 문제가 된다는 부분이다.
구글+ 의 경우 비동기 자바스크립트 로딩 방법을 사용해서 페이지 로드지연을 방지 할수있고.. 같은 주소를 사용함으로 그때 그때 받지 않고 브라우저 캐시를 사용해서 로딩 시킬 확률이 높을거 같다. 물론 결과적으로 없는게 빠르다.

체감속도가 느껴지는 작업
1. 자바스크립트 </body>부분 이동
2. 이미지 로딩 지연
3. 브라우저 캐시 극대화

결과적으로 HTTP 컨넥션을 줄이고 전송 트레픽양을 줄이는 것이 관건이다.

https://developers.google.com/speed/pagespeed/insights/

사이트 주소를 넣어보자 고쳐야 하는 부분들이 한글로 친절히 알려준다.

kernel: nf_conntrack: table full, dropping packet. 원인 및 해결방법

1. 발생상황
서버 접속자가 폭등하는 경우 발생


2. 발생로그

#] /var/log/messages
> nf_conntrack: table full, dropping packet.

3. 장애상황
/var/log/messages 에 위와 같은 로그를 다수 찍은 후 웹서버 다운


4. 해결방법
//현재 설정값 확인

#] cat /proc/sys/net/nf_conntrack_max

//설정값 변경(재부팅시 초기화)

#]echo 100000 > /proc/sys/net/nf_conntrack_max

//설정값 고정

#] vi /etc/sysctl.conf
> net.nf_conntrack_max = 100000

※ 참고사이트
발생원인
- http://idchowto.com/?p=927

해결방법
- http://jook.pe.kr/xe/linux/2424
- http://lost-and-found-narihiro.blogspot.kr/2012/11/centos-63-64bit-nfconntrack-table-full.html
- http://www.webstershome.co.uk/2014/08/27/nf_conntrack-table-full-dropping-packet/

특정 html 태그 제거(php)

문서의 원하는 특정 HTML 태그를 제거 할때 사용되는 방법이다.

보통은 strip_tags 함수를 사용하나 전체 HTML 태그를 삭제하거나 특정 태그만 사용이 가능하게 하는 기능만 있다. strip_tags 함수로 <a>태그만 삭제하고 싶다면 두번째 인자에 다른 허용 태그를 전부 입력해야 하므로 상황에 따라 이용하기 불편하다. 물론 특정태그 삭제하는 PHP 함수는 없다.

간단하게 preg_replace 함수를 사용해서 원하는 결과를 얻을 수 있다.

$str = "<a href=''>텍스트</a>";
$str = preg_replace("/<a[^>]*>/i", '', $str);
$str = preg_replace("/<\/a>/i", '', $str);
echo $str;

자주사용하거나 여러건의 태그삭제가 필요하다면 삭제처리 할 태그명을 배열로 받아 함수로 처리하면 좋을듯..

참고 : i 는 대소문자 구별하지 않음

bindParam / foreach, for 문등의 반복문 사용시 주의점

mysql_query 등 mysql_* 함수를 PDO로 변경하면서 bindParam 사용시 주의점.
bindParam의 변수 평가 시점에 따라 원하지 않은 결과가 나올 수 있다.

참고 : bindParam / bindValue 차이점 - (PHP PDO)


함수에서 배열로 변수를 받아 반복문 사용시 실수 하는 부분이다.(잘못된 예제)

$a['a'] = ':0';
$a['b'] = ':1';
$a['c'] = ':2';
$sth = $sth->prepare('SELECT name FROM students WHERE number_idx IN(".implode(",",$a).")');
foreach($a as $key=>$value) {
  $sth->bindParam($value,$key,PDO::PARAM_INT); 
} 
$sth->execute();

반복문을 실행시키더라도 execute(); 구문에서 변수가 평가되어 결과적으로 예상하지 않은 결과과 나오게 된다. bindValue로 변경시 원하는 결과를 얻을 수 있다.

MYSQL replication 에서 master 서버 비정상 종료/재부팅 처리방법

[master 서버가 다운되어 재부팅 후 slave의 replication 문제 발생했을 경우]

1. 원인
mysql이 재시작되면서 log 파일명의 일련번호가 바뀌면서 생기는 것으로 추정(1증가)

2. 조치
  1) slave의 mysql 에러 로그에서 master서버의 로그명 및 위치 확인 후 

  2) master 서버에서
      mysql> SHOW BINLOG EVENTS [IN '로그명'] [FROM 위치] [LIMIT [옵셋,] 줄수]
      명령을 통해 master 로그의 해당 위치 이후에 실행된 내용들이 있는지 확인한다.
      ※ 아무 내용이 없다면 slave의 mysql을 중지시키고 master.info와 relay-log.info 파일을  수정한다.
      ※ 혹시라도 master 로그의 해당 위치 이후에 쿼리가 있다면 먼저 조치를 해줘야겠죠...
      ※ 중복되는 쿼리가 있어 skip하고 싶을 경우
           mysql> STOP SLAVE;
           mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N;
                      ※ 일반적으로 하나의 쿼리를 skip할 경우 N=1로 하면되지만  auto increment 등이 포함된 경우 N=2로 해야겠죠.
          mysql> START SLAVE;

    3) master.info 파일 첫번째줄의 master로그명 수정(1증가), 2번째줄의 위치는 4로 수정

    4) relay-log.info 파일 3번째줄의 master로그명 수정(1증가), 4번째줄의 위치는 4로 수정
    ※ 어떤 경우 5번째 줄에 숫자가 있는 경우가 있는데 삭제 요망 (버그로 추정됨)

    5) slave의 mysql을 구동시킨다.

    6) show processlist 또는 show slave status 명령으로 정상동작여부 확인

※MYSQL replication 마스터-슬레이브 상황에서 마스터서버의 비정상적인 리부팅 현상으로 Peplication이 해제가 되어 위방법으로 복구
※ 마스터가 비정상적으로 재부팅되면서 로그.bin 파일의 일련번호가 1증가 되고 슬레이브는 이전 로그파일을 바라보는 현상 발생


출처 :http://www.lovelinux.net/xe/index.php?dummy=nnuvaujm&mid=linux&sort_index=readed_count&order_type=asc&page=4&document_srl=306