아파치 errors 로그에 다음과 같은 메세지가 기록되며 아파치 종료가 되지 않거나 강제종료 등의 문제가 발생할 경우

[alert] (11)Resource temporarily unavailable: setuid: unable to change to uid: 99

자원이 일시적으로 사용 불가능함


아파치 mpm 의 MaxClients 설정 등으로 인해 특정 uid (ex:nobody) 의 서버 프로세스가 시스템의 허용 수를
초과 하였는지 의심해 볼 수 있습니다.

특정 사용자의 사용가능한 프로세스의 최대갯수 제한

확인 :
ulimit -u

설정:
ulimit -u 2048

ulimit 설정은 현재 세션에서만 적용 되며 기본값을 변경하기 위해서는 /etc/security/limits.conf 파일에 다음과 같이 등록하면 됩니다.

(사용자) (soft or hard or all) (옵션) (값)
*                -      nofile          2048
root             -      nproc           2048

2013/01/29 17:50 2013/01/29 17:50
샤이 이 작성.

당신의 의견을 작성해 주세요.

1.OS 튜닝과 마찬가지로, 웹 서버도 튜닝작업을 수행한다고 해서 웹 서버가 지니고 있는 성능이 2~3배 이상 향상되는 일은 없다.

어디까지나 본래 지니고 있는 서버의 성능을 충분히 발휘할 수 있도록 조정하는 것이 튜닝 작업이다.

2.웹 서버 병목현상

과부하로 웹 서버가 응답을 제대로 반환하지 못할 경우, 그원인이 되는 것은 웹 서버의 설정과는 관계없는 것이 대분분이다.

웹 서버는 비교적 안정된 소프트웨어로, 자체만으로는 시스템에 부하를 유발하는 소프트웨어는 아니다.

드러난 웹서버의 응답불능상태의 원인을 이 웹 서버에 있다고 할 수는 없다. 열이 나고 있다고 해서 해열하는 것만으로는 병이 낫지 않는 것과 마찬가지다.

이 상황에서는 아무리 아파치 설정을 만진다고 해도 그 외의 부분에서 문제가 발생하고 있는 이상. 의미가 없다는 것을 의색해야 한다.

아파치 설정을 변경하면서 상태를 살펴보는 대책이 아닌, 장애 원인을 찾기 위한 지식이 가장 중요하다.

[추측하지 말고 계산하라]

문제의 상당수는 ps나 sar,vmstat등의 툴을 사용하면 파악할 수 있다.

한편 "하드웨어나 OS가 충분히 성능을 발휘할 수 있는 상태" 이면서 "부하가 큰 상황"에서, 웹 서버의 설정으로 족쇄가 되는 항목은 분명히 있다.

3. 아파치의 병렬처리와 [MPM-mulity processing module]

아파치를 비롯하여 불특정 다수의 클라이언트에 공개된 네트워크 서버는 동시에 복수의 클라이언트로부터 접속되더라도 계속해서 처리할 수 있도록 병렬처리를 수행할 필요가 있다.

병렬처리를 수행하지 않는 서버에서는 특정 클라이엍느가 접속해서 서버와 입출력을 하고 있는 동안, 다른 클라이언트 서버에 접속할 수가 없다.

특히 아파치를 시작으로 하는 웹 서버는 얼마나 많은 다수의 접속을 동시에 처리할 수 있는가가 성능의 기준이 되는 소프트웨어이므로, 병렬처리의 구현이 서버의 성능에 미치는 영향이 상당히 크다고 할 수 있다.

*병렬처리의 구현 모델

- 프로세스를 여려 개 생성해서 병렬처리를 실현하는 멀티 프로세스 모델 [prefork]

- 프로세스가 아니라 보다 경량의 실행단위인 쓰레드를 사용하는 멀티 쓰레드 모델 [Worker]

- 입출력을 감시해서 이벤트가 발샣아는 타이밍에 처리를 전환하는, 시그널 쓰레드로 병렬처리하는 이벤트 구동 모델 [event MPM-실험모듈]

4. prefork와 worker, 프로세스와 쓰레드

- prefork

: 기본적으로 프로세스간에 메모리를 직접 공유하지는 않는다. 메모리 공간이 독립해 있으므로 안전하다.

: 안전지향, 후방호환성이 높은 MPM

- worker

: 멀티쓰레드에서는 메모리 공간 전체를 복수의 쓰레드가 공유하므로, 리소스 경합이 발생하지 않도록 주의할 필요가 있다. 이것이 멀티쓰레드 프로그래밍이 복잡하다고 하는 이유다.

: 확장성이 높은 MPM

mod_perl을 worker로 작동시킬 경우에는 펄이 ithreads로 쓰레드를 생성한다. 펄의 쓰레드 구현은 다소 특수하기 때문에, prefork로 작동시킨 경우와는 다소 사양의 차이가 있다. 이를 꺼려해서 prefork를 선택하는 사용자가 많을 수 있다.

5. 성능관점에서 본 멀티프로세스/멀티쓰레드의 차이

일반적으로 멀티프로세스 보다 멀티쓰레드 방식이 가볍고 더 빠르다고 한다. 주된 이유는 다음 두가지다.

- 복수의 메모리 공간을 각각 지닌 멀티프로세스보다 메모리 공간을 공유하는 멀티쓰레드쪽이 메모리 소비량이 적다.

- 멀티쓰레드는 메모리 공간을 공유하고 있으므로, 쓰레드 전환에 걸리는 비용이 더 적다.

실제 아파치를 이용함에 있어서는 어떨까.

메모리 소비에 관해서는 실제 멀티쓰레드를 이용한느 worker에 손이 올라간다.

다만, prefork방식에서도 멀티프로세스의 부보 자식 프로세스에서 갱신이 되지 않는 메모리 공간은 공유되므로(실질적으로 초반에는 70%이상 메모리 공유가 있다), 현저한 차이가 나는 것은 아니다.

또 한가지는 "컨텍스트 스위치" 비용의 차다.

멀티태스킹 OS는 서로 다른 처리를 수행하는 처리단위로 프로세스/쓰레드를 짧은 시간에 전환하여 병렬처리를 실현하고 있다.

이 때의 프로세스/쓰레드 전환처리를 "컨텍스트 스위치"라고 한다.

따라서 멀티쓰레드방식인 worker는 메모리 공간을 공유하기 때문에 메모리 공간의 전환처리는 생략할 수 있고, 이는 이에 발생되는 CPU상의 메모리 캐시를 사용하지 않고 그대로 유지할 수 있게 하므로 성능에 미치는 영향은 현저하다고 할 수 있다.

->정리

- prefork를 worker로 변경하더라도 하나의 클라이언트에 대한 응답시간이 고속화되는 것은 아니다.

- prefork를 worker로 변경하더라도 메모리가 충반하다면 동시에 처리할 수 있는 접속 수는 변하지 않는다.

- prefork를 worker로 변경하더라도 대량의 컨텍스트 스위치가 없다면(동시에 병렬적으로 대량의 액세스가 없다면)효과는 크지 않다.

"prefork를 worker로 변경했더라도 성능이 개선되는 상황은 제한되어 있다."

"메모리 용량이 크지 않거나 소비량을 줄이고자 할 경우, 컨텍스트 스위치 횟수가 많아서(대량의 액세스) CPU의 리소스를 줄이고자 할 경우 worker 방식으로의 전환을 고려해 볼 필요가 있다"

6. 하나의 클라이언트에 대한 하나의 프로세스/쓰레드

둘의 공통점은, 아파치 클라이언트로부터 온 하나의 요청에 대해 기본적으로 하나의 프로세스 혹은 하나의 쓰레드를 할당해서 처리한다는 점이다.

즉 동시에 10개의 클라이언트로부터 요청이 있을 경우,10개의 프로세스 또는 10개의 쓰레드를 생성해서 응답한다.

따라서, 동시에 생성할 수 있는 프로세스/쓰레드 수가 아파치의 성능을 좌우하는 항목이 된다. 이러한 프로세스/쓰레드 수를 제어하는 설정항목의 최적화를 찾는 것이 아파치 튜닝의 핵심이라 할 수 있을 것이다.

7. httpd.conf 설정 - 아파치의 안전판 MaxClients

웹 서버는 "언제 어느 정도의 트래픽이 발생할지는 예상할 수 없다"는 점을 전제로 설계되어 있다.

그래서 아파치는 프로세스/쓰레드 수를 부하에 맞게 동적으로 제어하여 한다. 그러나 동적으로 제어한 결과가 머신의 리소스를 고갈시킬정도로 많은 프로세스/쓰레드를 생성하는 것이면 곤란하다.

이 때문에 안전판으로서, "동시에 접속할 수 있는 클라이언트 개수의 상한값"이 준비되어 있다. 이 안전판이 없다면 해당 시스템이 허용할 수 있는 수 이상의 요청이 동시에 몰려올 경우, 메모리를 다 써버려서 OS가 hang-up되거나 CPU사용률을 모두 점유해서 응답불가능 상태가 되는 치명적인 장애를 초래하게 된다.

오버 요청이 있을 경우 Maxclients는 다음 동작을 하게 된다.

-처리를 마치지 못한 용청에는 대기행렬내에서 일정시간 기다려 준다.

-대기행렬이 넘쳐날 듯 하면 해당 요청에 대해 에러를 반환해서 클라이언트로 응답을 돌려준다.

이로써 OS 자체가 hang-up되는 등의 쵝악의 사태를 피할 수 있게 된다.

이 상한값은 정적인 값이다. 머신이 지니고 있는 리소스에 맞게 수동으로 설정할 필요가 있다. 이 조정이 아파치 튜닝의 핵심이 된다. 반대로 이 외의 항목으로 성능에 영향을 미치는 것은 많지 않다.

prefork - MaxClients

prefork의 경우 안전판이 되는 것은 ServerLimit와 MaxClients 라는 두 가지 디렉티브로 설정된다. 둘 다 아파치가 생성하는 프로세스 수의 상한값이다.

-ServerLimit : 서버 수, 이를테면 프로세스 수의 상한

-MaxClients : 동시에 접속할 수 있는 클라이언트 수의 상한

본래는 위의 의미이지만 하나의 클라이언트를 하나의 프로세스에서 처리하므로 양자는 거의 같은 의미다. (같은 값으로 설정하면 된다.)

문제는 어느 정도의 값으로 설정하느냐인데, "이 값으로 해야 한다"라고 단정된 수치는 없다.

상한 수치를 계산하기 위해서는 다음 두 가지를 먼저 알아야 한다.

- 서버가 탑재되어 있는 물리 메모리의 양

-프로세스 하나당 평균 메모리 소비량

전자는 하드웨어 스펙을 참조하면 알 수 있다.(free 등의 명령)

후자는 ps나 top으로도 확인 가능하지만, proc 파일 시스템을 통해 조사해 보겠다.

cat /proc/프로세스 PID/status

[root@nehal-testweb1 proc]# cat /proc/27350/status
Name: httpd
State: S (sleeping)
SleepAVG: 98%
Tgid: 27350
Pid: 27350
PPid: 19888
TracerPid: 0
Uid: 99 99 99 99
Gid: -1 -1 -1 -1
FDSize: 64
Groups: -1
VmPeak: 160576 kB
VmSize: 160572 kB
VmLck: 0 kB
VmHWM: 14728 kB <- 해당 프로세스가 실제 사용하고 있는 메모리 영역의 크기가 된다.
VmRSS: 14724 kB
VmData: 10196 kB
VmStk: 84 kB
VmExe: 536 kB
VmLib: 15376 kB
VmPTE: 248 kB
StaBrk: 19d80000 kB
Brk: 1a70f000 kB
StaStk: 7fffe86b1f00 kB
Threads: 1
SigQ: 0/63488
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001200
SigCgt: 000000018400446b
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Cpus_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00ffffff
Mems_allowed: 00000000,00000001
[root@nehal-testweb1 proc]#

언뜻 보면 이 VmHWM 값으로부터 httpd의 각 프로세스의 평균값을 구하면 될 것처럼 보인다.

예를 들면 VmHWM: 14728 kB 의 경우 평균 메모리사용량을 15MB로 계산하고, 서버 총 메모리를 4GB, OS 할당을 512MB로 잡았을 경우 MaxClients의 값은 230이 되게 된다.

ex)

4GB(총) - 0.5GB(OS) = 3.5G

3.5GB/0.15GB = 230

그러나 이것만으로는 판단재료가 불충분하다. 리눅스는 물리 메모리를 절약하기 위해 부모 프로세스와 자식 프로세스에서 일부 메모리를 공유한다. 이런 공유 메모리를 고려하면 보다 큰 값을 설정하는 것이 가능하다.

"카피 온 라이트" -부모/자식 프로세스간 메모리 공유

모든 프로세스에는 부모 프로세스가 있다. prefork인 아파치의 경우 하나의 특정 httpd 부모 프로세스가 우선 가동해서 복수의 httpd 자식 프로세스를 생성한다. 부모와 자식은 서로 독립된 메모리 공간을 실현하기 위해 fork에 동반해서 부모로부터 자식에게 메모리의 내용을 있는 그대로 복사하지만 이러한 복사 처리는 매우 비용이 높은 처리이다.

그래서 리눅스는 fork 단계에서 가상 메모리 공간에 매핑된 물리 메모리 영역은 복사하지 않고 부모와 자식간에 이를 공유한다.

이러한 공유는 부모 자식에게 가상 메모리 공간은 각각 마련해 주고, 각각의 메모릭 공간으로 부터 동일한 물리 메모리 영역을 매핑함으로써 실현된다.

부모 혹은 자식이 가상메모리에 대해 쓰기를 수행하면, 해당 쓰기 작업이 수행된 영역만 더 이상 공유할 수 없게 된다.

역으로 쓰기 작업이 수행되지 않은 메모리 영역은 항상 계속해서 공유되어 있을 수 있으며, 이에 따라 메모리상의 페이지 중복을 피해서 메모리를 효율적으로 이용할 수가 있다.

이런한 구조를 " Copy on Write" 라고 한다. "쓰기 작업시에 복사한다" 라는 의미다.

카피 온 라이트로 공유 메모리 사이즈 확인

MaxClients를 설정하려면 실제로 사용하고 있는 메모리 영역 내의 공유 물리 메모리 크기도 고려할 필요가 있다.

공유 메모리 영역은 /proc/프로세스PID/smaps 의 데이터 참조로 확인할 수 있지만, 데이터량이 많으므로 그 자체로는 어렵다.

============================================================================
출처 : http://joe0912.blog.me/60101396833

2013/01/29 17:14 2013/01/29 17:14
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치 멀티 프로세싱 모듈 옵션 설정 시

MaxClients를 256 이상 설정하기 위해서는 아파치 소스를 수정하고 컴파일 해야 한다는 걸로
알고 있는 경우가 많습니다.

아파치 2.x 버전 이상부터는 소스에 최대치가 20000 으로 설정이 되어 있기 때문에 20000 이하는
따로 소스를 수정하고 컴파일 할 필요가 없습니다.

사용시에는 ServerLimit값을 MaxClients 보다 먼저써야되고 크게 잡아줘야 됩니다.

ex) httpd-mpm.conf

<IfModule mpm_prefork_module>
    StartServers             500
    ServerLimit             2000
    MinSpareServers       500
    MaxSpareServers       700
    MaxClients              2000
    MaxRequestsPerChild  500
</IfModule>
2013/01/29 17:08 2013/01/29 17:08
샤이 이 작성.

당신의 의견을 작성해 주세요.


MySQL 파라메터 중
skip_name_resolve





MySQL 레퍼런스를 보면


"skip_name_resolve를 적용하게 되면 MySQL 서버가 클라이언트들의 접속시 DNS LOOKUP 과정을
생략시킨다."



 


덧붙여서 인터넷에 있는 글들을 본다면 "그러므로 속도가 빠르다" (인터넷 대부분의 글들) ...... 라고
설명이 되어 있다.



 



오라클은 접근 하려는 스키마의 ID와 패스워드를 알고 있는 상태에서 각 서버간의 네트워크 접근 권한만 허용된다면,


리스너를 통해 마음대로 접속할 수 있다. ( 물론 sqlnet.ora 파일에 접근 제한 설정이 안된 상태)



 


하지만 그와 다르게 MYSQL은 DB가 자체적으로 ID PASSWORD
그리고 IP(HOST)를 체크한다.


위 3가지 조건 중 하나라도 만족을 하지 못한다면, DB에 접근 할 수 없다.



 


MYSQL의 계정 권한이 저장된 USER 테이블을 조회한다면 이러한 결과값을 볼수 있다.


(또한 hash 함수로 암호화 저장 되어 있는 password를 볼 수 있다.)



 


mysql> select user, host , password from
mysql.user;
+----------+---------------------+-------------------------------------------+
|
user | host |
password
|
+----------+---------------------+-------------------------------------------+
|
root | localhost |
*E74858DB86EBA20BC33D0AECAE8A8108C56B17FA |
| repl |
% | *A424E797037BF97C19A2E88CF7891C5C2038C039 |
| dumpuser
| 192.168.100.100 | *56C09388C92050AD66D96D207790DFBA76CD410B |


| testuser | kthcorp |
*56C09388C92050AD66D96D207790DFBA76CD410B
|
+----------+--------------------+-----------------------------------------------+



 


해당 계정들을 대상으로 하여서 서버로의 접근 상황을 예로 든다면


일단 해당 ID와 패스워드를 모두 알고 있다고 하여도 모든 계정들의 접근에는 제한이 있다.


왜냐하면 host 컬럼에 등록된 IP 권한들이 모두 다르기 때문이다.



 


1. root 계정의 경우 localhost 로 등록되어 있어서 로컬에서만 접근이 가능하다.


(보안상 root는 로컬에서만 접근하도록 허용하는 것이 좋다.)



 


2. repl 계정의 경우 %로 되어 있다.


%는 어디서 접근을 하던지 간에 무조건 id와 패스워드만을 알고 있다면 접근을 허용 해준다.



 


3. dumpuser의 경우 192.168.100.100이라는 곳에서만 접근을 허용 해준다.



 


4. testuser의 경우 kthcorp라는 호스트를 가진 클라이언트가 접근 요청시에만 허용
해준다.



 


위의 1,2,3 의 경우는 모두 MYSQL 서버가 클라이언트 접근 요청시 자체적으로 판단이 가능하다는 것을 알 수 있다.


하지만 4번의 경우 MYSQL이 kthcorp 라는 호스트명을 가진 서버가 어느 서버인지를 알 수가 없다.



 


그러므로 4번 testuser 계정이 접근을 요청할 경우,


MySQL 서버는 먼저 /etc/hosts 파일에서 kthcorp라는 호스트명을 가진 서버의 ip를 체크하여 접근을 허용해준다.



 


가상의 시나리오를 한가지 생각하자면,


MySQL 서버에 저러한 host명으로 등록된 계정들이 굉장히 빈번하게 접근할 경우,


그 때마다 MYSQL은 일일이 hosts 파일을 체크하며, 접근을 제한하려 하므로 서버에는 부하가 생길 것이다.


그러므로 skip_name_resolve 라는 파라메터를 설정하여 이러한 룩업 과정을 생략함으로,


서버에 접근 부하를 줄일수 있다고 한다면 이 얼마나 좋은 상황인가.....?



 


하여 직접 테스트를 해보았다.


결론은 skip_name_resolve 파라메터를 적용한다면, 위의 룩업 과정을 생략한다.


그런데 중요한 점은 인증 과정을 생략하고 접근을 허용해주겠다는 의미가 아니라,


이러한 인증 없이 그냥 HOST로 등록된 계정들은 무시하겠다는 의미이다....


그러므로 skip_name_resolve 파라메터를 적용한 순간부터는 HOST명으로
등록된 계정들은 모두 서버에 접근할 수 없다.


(localhost, ip, %로 등록된 계정만 접근할 수
있다)



 



일반적으로 DBA 조직이 운영하는 서비스 DB에서는


산발적으로 개별 클라이언트들을 모두 MySQL 서버로 붙게 하는 구성은 하지 않을
것이다.


DB 앞단에 존재하는 WAS 서버에서 커넥션을 조절하며, 관리를
하기에


이러한 skip-name-resolve와 관련된 이슈 사항을 접할 일은 사실상 흔치 않을 것이다.



 



/etc/hosts 파일과 mysql.user 테이블의 상호 연관성 테스트 시나리오



 


1. MySQL 서버 hosts 파일에 등록된 클라이언트 서버의 host ip 부분을 삭제 한후,


클라이언트에서 host로 등록된 계정 접속을 시도할 경우 접근이 불가능함을 알 수 있다.


단 최초 mysql 서버 오픈 이후 이미 인증한 hosts에 한해서는 hosts 파일을 삭제해도 접근이 가능함을 알 수 있다.


(메모리에 host 정보 기록됨)



 


2. skip_name_resolve 설정된 MySQL 서버에 /etc/hosts가 등록된 계정으로도 접근 불가능함을 알 수
있다.

=====================================================================
출처:http://www.cyworld.com/oracooler/9179996

2012/12/20 16:16 2012/12/20 16:16
샤이 이 작성.

당신의 의견을 작성해 주세요.

사용자 삽입 이미지
센토사 섬에 위치한 유니버셜 스튜디오.
정문 앞의 거대한 조형물이 내가 어디에 있는지 뚜렷하게 알려주고 있다.
매표소 앞 안내하는 아가씨가 우리가 한국인 이라는 것을 알아보고
신이나서 한국말로 안내를 해준다 아르바이트 하는 학생쯤으로 보이는데
한국에 우호적인 것 같아 기분이 좋다.


사용자 삽입 이미지
유니버셜 스튜디오는 여러 영화들을 컨셉으로 여러가지 즐길 거리를 만들어 두었는데
그 중 하나인 영화 "미이라"를 컨셉으로 한 놀이시설 입구.
롯데월드 매직아일랜드에 있는 지하 롤러 코스터에 미이라 영화 분위기를 첨가 했다고 생각하면 맞을듯..
가장 재밌는 놀이기구는 트랜스포머 와 배틀스타 갤럭티카.
사실 놀이기구의 수는 그렇게 많지는 않아 유니버셜 스튜디오 입장권이 꽤나 비싸게 느껴짐.


사용자 삽입 이미지
비가 내리는 타이밍에 입장한 워터월드.
망한영화 "워터월드"를 컨셉으로 쇼를 보여주는 내용으로 간략한 줄거리는
"나쁜놈들이 쳐들어와 남자 주인공이 여자주인공을 구출한다" 라는 내용.


사용자 삽입 이미지
쇼를 시작하기 전에 20여분 동안 배우들이 이러고 놉니다..
좌석은 색깔별로 존이 구분되어 있는데 앞쪽 구역에 앉으면 물벼락을 맞는다는..
마구 물을 뿌리는 와중에도 안전구역은 철저히 지킴.. 메인 쇼가 시작되고 나서도
모터보트 등등으로 마구 물을 뿌려준다. 물에 젖기 싫은 사람은 좌석을 고를때 신중히..

사용자 삽입 이미지
악당A의 특수능력 공중비행!
사용자 삽입 이미지
우리나라에도 아시아 최대 규모의 유니버셜 스튜디오 건설중이라고 하는데
얼마전에 부지 가격과 관련해서 논란이 있다는 기사를 본 듯함.
전체적인 분위기는 다른 유원지들과 크게 다를바는 없는듯 하다.


사용자 삽입 이미지

사용자 삽입 이미지
얌차에서 몇년 분의 딤섬을 몰아서 먹는 바람에 딤섬따위 쳐다보기도 싫었지만
미식가인 친구녀석이 꼭 먹어봐야 한다고 하는 바람에 들어간 "딘타이펑"
물 한잔에도 돈을 받는다 ㅋ.. 닭고기국물 딤섬국수와 꼭 먹어야 한다는 소룡포.
딤섬따위 보기도 싫었지만 맛있다...
딘타이펑은 한국에도 분점이 있으니 기회되면 들려봐야 할 듯.


사용자 삽입 이미지
이탈리아에서 젤라또를 너무 맛있게 먹어 거금 6천원 가량의 젤라또를 샀는데
화남.. 가격은 몇배 맛은 절반 ... 비추

사용자 삽입 이미지
싱가폴 ver 먹자골목 이름은 기억이 잘 안남..
현지인들이 많이 가는 곳이라는데 외국들은 대체로 한국과 달리 밖에서 사먹는걸 더 많이 하는 분위기 인듯
그러고보면 차이나타운의 아파트에도 부엌은 없는 구조 였던걸로 기억된다...
들어가 보진 않았지만 구조상 없는걸로...



사용자 삽입 이미지

한국인들이 꼭 먹는다는 칠리크랩.
숙소의 주인 아저씨 께서 "점보 씨푸드" 칠리크랩의 부당한 가격에 대하여 열변을 토하셔서
(주인장 아저씨의 말에 따르면) 맛이 비슷한 현지인들이 자주 찾는 합리적인 가격의 음식점
(이라고 쓰고 주인 아저씨가 소개료로 커미션을 받는 듯한 음식점.)에서 칠리 크랩을 먹었다.
떡볶이 양념과 살짝 비슷한 느낌이 드는 달콤한 칠리소스에 미니번을 찍어먹는 맛이 일품
게를 먼저 먹고 밥을 비벼 먹으면 정말 맛있다. 싱가폴에 오면 역시나 꼭 먹어봐야할 1순위
그 유명한 "점보 씨푸드" 표 칠리크랩도 괜찮을 것 같다 사실 가격과 맛은 그렇다 치고 시원한
강바람을 맞으면서 깔끔한 테이블에 분위기 있게 먹는 것도 나쁘지 않다고 생각 된다.
숙소 주인 아저씨는 깔끔하게 차려입고 양손으로 게를 뜯어먹는 것도 웃기다고는 하지만~

사용자 삽입 이미지

사용자 삽입 이미지
또 하나의 싱가폴 명물 사태.
현지인들이 맥주와 함께 즐겨 먹는 안주 중 하나
쉽게 말하자면 소스에 찍어먹는 직화구이 꼬치구이들.. 맛은 있는데 딱히 닭꼬치 보다 월등히 뛰어나다
라는 생각은 들지 않는다. 비첸향에서 사온 육포를 꺼내놓고 같이 먹으니 서빙하는 아주머니가
멋진 안주라며 엄지 손가락을 치켜듬 사실 칠리크랩이 소화가 다 되지 않아 더 맛이 별루 였었던 걸지도...

개인적으로 별 생각 없이 갑작스레 가기도 했고 비행기값을 투자한데 비해 일정도 짧았기에 뭔가 좀 아쉬움이
남는 싱가폴 여행.
물가도 생각보다 비싸긴 하지만 깔끔하고 치안이 좋아 가볍게 다녀오기에 좋은 여행지 인 것 같다.

한줄평 : 야경 분위기가 정말 매력적인 멋진 도시!
주의 : 꼭 연인이랑 갈것!

2012/10/24 23:49 2012/10/24 23:49
샤이 이 작성.

당신의 의견을 작성해 주세요.

: 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 27 :