최근 이클립스가 버벅대서 오랜만에 이클립스 속도 향상 정보를 정리해본다.

eclipse.ini 수정

1) Before

-startup

plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar

–launcher.library

plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.1.R36x_v20100810

-product

org.eclipse.epp.package.jee.product

–launcher.defaultAction

openFile

–launcher.XXMaxPermSize

256M

-showsplash

org.eclipse.platform

–launcher.XXMaxPermSize

256m

–launcher.defaultAction

openFile

-vmargs

-Dosgi.requiredJavaVersion=1.5

-Xms40m

-Xmx512m

2) After

-vmargs

-Dosgi.requiredJavaVersion=1.6

-Xverify:none

-XX:+UseParallelGC

-XX:-UseConcMarkSweepGC

-XX:+AggressiveOpts  ==> 적용시 Location Type Conversion to Dalvik format failed 에러남

-XX:PermSize=128M

-XX:MaxPermSize=128M

-XX:MaxNewSize=128M

-XX:NewSize=128M

-Xms512m

-Xmx512m

위 에러 발생시

libfcgi/fcgio.cpp 파일에 #include <cstdio>  추가 후 컴파일

http://pkgs.repoforge.org/rpmforge-release/ 자신의 os 맞는 rpm 다운로드 후 설치

1. lighttpd 설치
# yum install lighttpd -y

2. php 설치
# yum install lighttpd-fastcgi php-cli

3. php에서 MySQL을 지원하기 위한 패키지 설치
# yum install php-mysql php-gd php-imap php-ldap php-odbc php-pear php-xml php-xmlrpc php-xcache -y

4. php.ini에 아래 내용 추가
# echo ‘cgi.fix_pathinfo = 1′ >> /etc/php.ini

5. lighttpd 설정(자신의 서버에 맞게 알아서..)
# vi /etc/lighttpd/lighttpd.conf

Error : couldn’t set ‘max filedescriptors’ Permission denied 발생시
/etc/sysconfig/selinux 파일의
SELINUX=enforcing 을 SELINUX=disabled 로 교체후 리붓

source : proftpd-1.3.3ekr.tar.bz2
os : centos 6.2 x86_64

1. http://mirror.oops.org/pub/oops/proftpd/ 에서 파일을 다운로드 받는다.

2. 다운로드 받은 파일의 압축을 해제 한다.
# tar xfvjp proftpd-1.3.3ekr.tar.bz2

3. 압축해제된 디렉토리명을 변경한다.
# mv proftpd-1.3.3ekr proftpd-1.3.3e

4. 재압축 한다.
# tar cfvjp proftpd-1.3.3e.tar.bz2 proftpd-1.3.3e

5. 소스 rpm으로 빌드 한다.
# rpmbuild -ts –target x86_64 proftpd-1.3.3e.tar.bz2

6. 생성된 SRPM을 설치한다(/root/rpmbuild/SRPMS)

7. 생성된 SPEC 파일을 수정한다
%{_libdir}/pkgconfig/*.pc
/usr/lib/pkgconfig/*.pc

8. 생성된 SPEC 파일로 다시 RPM으로 빌드 한다 ( /root/rpmbuild/SPECS )
# rpmbuild -ba –with ctrls –with mod_facl –with mod_tls –with nls –with dso –target x86_64 proftpd.spec

9. /usr/src/redhat/RPMS/i686/에 생성된 rpm 파일들을 확인후 설치 해본다…

설치 후 아래 에러가 날경우

- notice: unable to bind to Unix domain socket at ‘/var/run/proftpd/test.sock’: No such file or directory
- notice: unable to listen to local socket: Operation not permitted
127.0.0.1 – mod_delay/0.6: error opening DelayTable ‘/var/run/proftpd/proftpd.delay’: No such file or directory
127.0.0.1 – notice: unable to listen to local socket: Operation not permitted

/var/run에 proftpd 디렉토리를 생성해준다~

위와 같은 에러 발생시
# chcon -t textrel_shlib_t /usr/local/apache/modules/libphp5.so

위와 같은 오류 출력시

ext/mysqli/mysqli_api.c 파일의 gptr을 char* 모두 변경 후 컴파일~

정보는 흘러 넘치고 분석해야 할 데이터도 계속 커지면서 많은 데이터를 효율적으로 운영하기 위한 노력들은 계속 진행 중이다. 이 같은 추세에 발 맞춰 최근에는 어플라이언스 시장도 국내에서 계속 커지고 있다. 대용량 데이터를 처리하기 위해 테이블 파티셔닝은 DBMS의 필수 기능으로 꼽히는데 MySQL이 테이블 파티셔닝을 지원하지 않는 것은 그 동안 MySQL을 대용량 DB에서 쓰기 어려웠던 이유이기도 했다. Merge 테이블을 이용해 일부 비슷한 효과를 낼 수는 있었지만, 정식으로 테이블 파티셔닝을 지원한 것은 5.1 버전부터다. 지금부터 MySQL Partitioning에 대한 이야기를 시작해 보자.

5.1버전의 테이블 파티셔닝 지원은 타 상용 DBMS에 비해 아직은 부족한 수준임을 감안해도, 이제껏 MySQL의 파티셔닝 기능에 목말라 있던 사용자들에겐 단비와 같은 소식이다. 일반적으로 테이블을 파티셔닝한다면 다음과 같은 기대를 가지고 있을 것이다.

- 특정 데이터 집합의 추가/삭제가 간편하다. – 데이터 검색 시 특정 파티션만 읽어서 속도를 향상시킬 수 있다. – 병렬 처리가 가능하다. – 한 테이블에 너무 많은 데이터가 입력되었을 시 발생하는 속도 저하를 방지할 수 있다.

그렇다면 위와 같은 기대를 어느 정도 충족해 주고 있는지 MySQL 파티셔닝 사용법과 특징에 대해 살펴보자. 먼저 자신이 사용하고 있는 MySQL에서 파티셔닝을 지원하는지 확인하는 방법은 <리스트 1>과 같다.

파티션 타입

MySQL에서 지원하는 파티셔닝 종류에 대해 살펴보자. 기본적으로 MySQL은 RANGE, LIST, HASH, KEY 파티셔닝을 지원한다. 많이 사용되는 파티셔닝은 모두 지원한다고 보면 되겠다.

RANGE

특정 범위 단위로 파티셔닝할 때 적용되는 가장 흔히 사용하는 파티셔닝 타입 중 하나이다. Create table 구문 뒤의 PARTITION BY RANGE() 절 안에는 파티셔닝할 컬럼을, VALUE LESS THAN() 절 안에는 해당 파티션의 MAX 값을 기술하면 된다. <리스트 2>를 예로 들어보자.
이 테이블을 store_id 컬럼에 의해 Range 파티셔닝하고 싶다면 <리스트 3>과 같이 정의한다.
데이터가 들어갈 파티션은 VALUES LESS THAN 구문에 의해 결정된다. <리스트 3>의 예제에서는 store_id가 1~5까지는 p0 파티션, 6~10까지는 p1 파티션으로 들어간다. 그렇다면 store_id에 21 값이 들어오면 어떻게 될까? 이때는 해당 값이 들어갈 파티션이 지정되어 있지 않기 때문에 에러가 발생한다. 따라서 어떤 값이 들어오더라도 에러가 나지 않도록 <리스트 4>와 같이 MAXVALUE를 지정할 수 있다.
21보다 크거나 같은 값이 들어오면 p4 파티션에 데이터가 들어갈 것이다. MAXVALUE는 이 타입이 가질 수 있는 가장 큰 값을 의미하고 제일 마지막 파티션에 기술해야 하며 오직 하나의 파티션에만 사용할 수 있다. 그에 반해 NULL 값은 다른 값보다 작은 값으로 인식되어 제일 작은 값으로 정의된 파티션으로 들어간다. 파티션 기준이 되는 컬럼은 VALUES LESS THAN 의미처럼 크기 비교가 가능해야 한다. 컬럼이 문자인 경우에도 문자 연산을 통해 숫자만을 걸러 낼 수 있다면 Range 파티셔닝이 가능하다.

Ex) PARTITION BY RANGE ( YEAR(separated) )

Range 파티셔닝은 다음과 같은 경우 유용하다.

- 대량의 과거 데이터를 지우기를 원할 때 : delete로 많은 데이터를 지운다면 시간이 오래 걸리지만 파티션별로 drop하면 순식간에 데이터 삭제가 가능하다

ALTER TABLE employees DROP PARTITION p0;

- 시간이나 날짜별로 데이터를 관리하고 싶을 때 – 파티션된 컬럼을 조건으로 쿼리를 자주 실행시킬 때

SELECT COUNT(*) FROM employees WHERE YEAR(separated) = 2000 GROUP BY store_id;

MySQL은 재빨리 해당 파티션만 읽어서 결과를 얻어낼 수 있다.

LIST

List 파티셔닝은 여러 가지로 Range 파티셔닝과 비슷한 점이 많다. Range 파티셔닝처럼 각각의 파티션은 명시적으로 정의되어 있어야 한다. Range 파티셔닝과 가장 다른 특징은 파티션을 결정하는 컬럼 값이 범위가 아니라 특정한 값들의 집합이라는 것이다.
Partition by list() 절에 파티셔닝할 기준 컬럼을 명시해 주고 values in() 절에 파티션을 구성할 값들을 지정하면 된다. VALUES IN() 절에 나열되는 값들은 연속될 필요가 없고 중간 값이 없어도 되지만 해당 파티션에 값이 하나도 없거나 여러 파티션에 중복된 값을 넣으면 에러가 난다. Range 파티셔닝에서의 MAXVALUE에 상응하는 것은 없고, value list에 null 값이 들어갈 수 있다. 삭제하고자 하는 데이터들이 해당 파티션에 있는 모든 데이터들이라면 역시 drop 구문을 이용해서 데이터를 삭제할 수 있다.

DELETE FROM employees WHERE store_id IN (4,12,13,14,18);

이와 같이 지우고자 하는 데이터가 pWest 파티션에 있는 모든 값이라면 해당 파티션을 drop함으로써 해당 값들을 모두 삭제할 수 있다.

ALTER TABLE employees DROP PARTITION pWest;

List 파티셔닝 역시 파티셔닝할 컬럼은 정수만 지원한다. 따라서 integer나 null이 아닌 값으로 파티셔닝하고 싶다면 파티션 기준 컬럼을 이러한 값으로 변환시켜야 한다. Job_code 값이 다음과 같이 들어온다고 가정해 보자

Management – D, M, O, P Sales – B, L, S Technical – A, E, G, I, T Clerical – K, N, Y Support – C, F, J, R, V Unassigned “Empty”

이렇게 문자로 들어온다면 이것은 integer value-list로 표현할 수 없으므로, 이럴 때 ascii() 함수를 사용해야 한다. list에 해당하는 값이 대소문자를 구별하지 않기를 원한다면 ucase 함수로 먼저 감싸고 ascii()를 사용하면 된다. 주의해야 할 점은 다음과 같은 insert 문은 실패한다는 것이다.

INSERT INTO employees VALUES (224, ‘Linus’, ‘Torvalds’, ‘2002-05-01’, ‘2004-10-12’, ‘Q’, 21);

Q의 ascii 값은 81인데 list 파티션 정의에 81에 해당하는 파티션이 존재하지 않기 때문이다. List 파티셔닝은 VALUES LESS THAN(MAXVALUE)과 비슷한 catch-all에 대한 정의가 없으므로 모든 list 값은 반드시 해당하는 파티션이 미리 정의되어 있어야 한다. 또한 MySQL 버전에 따라서는 PARTITION BY LIST() 절에 함수를 사용하지 못할 수도 있다. 최근 버전인 MySQL(5.1.36)에서는 PARTITION BY LIST() 절에 함수를 이용하지 못한다. 그러므로 integer 형이 아닌 컬럼을 기준으로 List 파티셔닝을 하고 싶다면 반드시 먼저 자신이 사용하는 MySQL 버전에서 테스트 후 사용하기를 바란다.

HASH

파티셔닝은 필요한데 마땅히 파티셔닝할 기간이나 특정 값들의 집합을 정의하기 모호할 때 보통 많이 사용한다. 사용 목적도 그렇듯이 Range나 List로 파티셔닝된 테이블을 생성할 때와는 달리 각각의 파티션들을 직접 정의해 줄 필요가 없다. <리스트 7>과 같이 PARTITIONS 절 뒤에 사용할 파티션 개수를 적어 주면 된다.
PARTITION BY HASH() 절에 역시 숫자 형식의 컬럼 값이 들어오면 된다. 숫자 컬럼이 아닐 경우 함수를 사용해 숫자로 변형이 가능하다면 Hash 파티셔닝이 가능하다. 그렇다면 각각의 데이터는 어느 파티션으로 들어가는 것일까? 내부적으로 파티션은 0, 1, 2, 3과 같은 식으로 번호가 붙여지는데 표현식을 expr, 파티션 수를 num이라고 하면, 입력되는 row가 들어갈 파티션 번호는 다음의 식으로 결정된다.

IF(ISNULL(expr), 0, ABS(expr)) MOD num

따라서 컬럼이 auto_increment 컬럼과 같이 순차적인 값을 가지는 경우 파티션별로 데이터가 고르게 분산된다.

CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE) PARTITION BY HASH( YEAR(col3) ) PARTITIONS 4;

이러한 테이블에 col3 값이 ‘2005-09-15’라면 데이터가 어느 파티션에 들어갈지는 다음과 같은 공식으로 계산된다.

MOD(YEAR(‘2005-09-01’),4) = MOD(2005,4) = 1

MySQL은 또한 Linear Hash 파티셔닝을 지원한다. 문법은 partition by hash가 partition by linear hash로 바뀌는 것 외에는 동일하다.
내부적으로 데이터를 파티셔닝하는 Hash 알고리즘으로 linear powers-of-two를 사용하며 참고로 LINEAR HASH() 절에 사용된 표현식을 expr, 파티션 수를 num, 들어갈 파티션 번호를 N이라고 했을 때 N을 구하는 방식은 다음과 같다.

1. V = POWER(2, CEILING(LOG(2, num))) 2. N = expr & (V – 1) 3. While ( N >= num: ) V = CEIL(V / 2) N = N & (V – 1)

KEY

Key 파티셔닝은 Hash 파티셔닝과 비슷하다. Hash 파티셔닝은 사용자가 정의하는 함수가 이용되는 반면 Key 파티셔닝은 MySQL에 의해 제공하는 Hash 함수를 사용한다. MySQL Cluster는 Hash 함수로 MD5()를 사용한다.
특이하게 KEY() 절에 컬럼을 명시하지 않아도 에러가 나지 않는데 명시하지 않으면 PK가 파티셔닝 키로 사용된다. 만약 해당 테이블에 PK가 없다면 UK가 파티셔닝에 사용된다.
하지만 UK가 파티셔닝 키로 사용되려면 반드시 UK가 not null로 정의되어 있어야 한다. <리스트 10>의 경우는 id 컬럼이 UK이긴 하지만 not null로 정의되어 있지 않아 실패한 것이다. 다른 파티션과는 다르게 유일하게 Key 파티셔닝에서는 파티셔닝 키값으로 숫자나 null 이외의 값을 사용할 수 있다. <리스트 11>과 같이 파티셔닝 키가 되는 컬럼 자료형이 char이라도 굳이 integer로 변환할 필요가 없다.

SUBPARTITIONING

파티션 안에 또 다른 작은 파티션을 만들 수 있다. Range나 List 파티션 안에 서브 파티션으로 Hash나 Key 파티션을 만드는 것도 가능하다. 여러 가지 파티셔닝을 함께 사용할 수 있기 때문에 Composite 파티셔닝이라고도 알려져 있다.

Partition Managemt

MySQL 상에서 파티셔닝한다면 주로 성능보다는 관리적인 면에서 더 유용하다. 월별로 관리하는 데이터를 Range 파티셔닝했다면 매달 말에 다음 달에 대한 파티션을 미리 만들어야 할 필요가 생긴다.
<리스트 13>에 정의된 파티션 테이블에 2009년 10월 데이터를 쌓을 파티션을 추가하고 싶다면 다음과 같이 추가할 수 있다.
mysql> ALTER TABLE in_ptest ADD PARTITION -> ( PARTITION p200910 VALUES LESS THAN (to_days(‘2009-11-01’)) ); Query OK, 0 rows affected (0.00 sec) Records: 0 Duplicates: 0 Warnings: 0

또한 특정 파티션을 간편하게 제거할 수도 있다.

mysql> ALTER TABLE in_ptest DROP PARTITION p200902; Query OK, 0 rows affected (0.57 sec) Records: 0 Duplicates: 0 Warnings: 0

짧은 시간 내에 Add, Drop이 되므로 온라인 중에서도 사용할 수 있다. 또한 다음과 같은 작업을 필요한 파티션만 진행할 수 있다. 해당 파티션만 작업하기 때문에 범위가 작아져 전체 작업하는 것보다 속도 향상이 있다.

ALTER TABLEREBUILD PARTITION; ALTER TABLEOPTIMIZE PARTITION; ALTER TABLEANALYZE PARTITION; ALTER TABLEREPAIR PARTITION; ALTER TABLECHECK PARTITION;

하지만 타 DBMS처럼 병렬 처리 효과를 얻기는 아직까지는 힘들다. <리스트 14>와 같이 서로 다른 두 파티션을 순차적으로 check할 때보다 제 각기 다른 세션에서 병렬로 처리할 때 속도가 빠를 것이라고 기대했지만 다음에서 볼 수 있듯이 실제 결과는 그렇지 않았다.
<리스트 14>에서 p200903, p200904 파티션을 순서대로 check할 때는 10초, 20초 걸리던 것이 <리스트 15>와 <리스트 16>처럼 각기 다른 세션에서 한꺼번에 실행시켰을 때는 각각55초, 54초가 걸렸다. 또한 보통 테이블 파티셔닝을 하면 특정 파티션에 어떤 작업을 수행할 때 다른 파티션에는 영향을 미치지 않을 것을 기대하지만 아직 MySQL에서는 이러한 점을 지원하지 않으니 유의해야 한다.
기존의 파티션을 병합하거나 분리하는 작업도 REO RGANIZE PARTIION 구문을 이용하면 가능하다. <리스트17>은 p200901 파티션과 p200902 파티션을 병합하는 것이다. 파티션 Add와 Drop은 순식간에 이뤄져 애플리케이션 운영 중에도 가능하지만 Reorganize를 하면 작업 대상이 아닌 파티션에 어떤 영향을 미칠까?
<리스트 17>의 세션에서 실행되는 쿼리는 p200901,p200902 파티션만 관여한다. 따라서 해당 파티션만 lock이 걸리고 나머지 파티션은 사용할 수 있을 것으로 기대하겠지만 실제 테스트 결과 <리스트 19>의 결과를 보면 알 수 있듯이 해당 파티션뿐만 아니라 전체 파티션에 lock이 걸리는 걸 알 수 있었다. <리스트 19> 쿼리의 데이터는 p200909 파티션으로 들어감에도 불구하고 <리스트 17>의 쿼리가 끝날 때까지 대기한 후에 실행이 되었다. 따라서 파티셔닝 관리 작업 중 Add와 Drop 같이 순식간에 이뤄지는 종류를 제외하고는 항상 애플리케이션에 영향을 줄 수 있다는 점을 명시하고 작업해야 한다.
현재 테이블 파티셔닝 현황에 대해 조회해 보고 싶다면 Information 스키마의 Partitions 테이블을 참조하면 된다.

파티션 성능

MySQL은 Parallel Processing을 아직 지원하지 않는다. 그렇더라도 각각 파티션에 해당하는 작업을 여러 개의 프로세스로 돌리면 비슷한 효과를 얻을 수 있지 않을까 기대했었지만 앞에서 살펴본 바와 같이 그러한 결과는 얻을 수 없었다. delete 대신에 drop 명령어를 통한 성능 향상, 그리고 Partition Pruning을 통한 성능 향상 정도를 기대할 수 있겠다.
Explain Partitions 구문을 사용하면 실행계획에 파티션 정보들을 보여준다. <리스트 20>의 세션에서는 파티셔닝 컬럼인 term이 where 조건에서 변형되었기 때문에 Partition Prunining이 일어나지 않았다. 따라서 <리스트 21>과 같이 파티션 키 컬럼은 그대로 두고 비교하는 상수 값만 변경해야 원하는 속도를 얻을 수 있다.

파티션 제약사항

글 중간 중간에 MySQL 파티셔닝을 사용할 때 제약사항들을 언급했었는데 현재 MySQL 5.1.36 버전에서의 제약사항들을 간단히 정리해 보면 다음과 같다. 아직까지는 생각보다 많다.

- 모든 파티션은 동일한 스토리지 엔진 사용 모든 파티션은 동일한 스토리지 엔진을 사용해야 한다. 파티션별로 스토리지 엔진을 명시해도 에러가 나지 않는 것을 봐서는 향후에 파티션별로 다른 스토리지 엔진을 사용할 수 있게 되지 않을까라는 기대도 해본다. 명심할 것은 파티션별로 스토리지 엔진을 명시해도 에러만 나지 않을 뿐 실제로 다른 스토리지 엔진을 사용할 수 있는 게 아니란 사실이다.

- Merge, CSV, Blackhole은 파티셔닝이 불가능하다. – 파티셔닝을 테이블이나 인덱스만 할 수는 없다. 테이블과 인덱스를 항상 같이 파티셔닝해야 한다. – 파티션된 테이블은 foreign key를 지원하지 않는다. – 파티션된 테이블은 fulltext index를 지원하지 않는다. – 파티션된 테이블은 geometry 컬럼을 지원하지 않는다. – Key 파티셔닝을 제외하고는 파티셔닝에 키가 되는 컬럼은 반드시 integer 값이거나 integer로 변환 가능해야 한다. null은 포함될 수 있다. – 많은 테이블에 파티션을 사용하다 보면 스토리지 엔진으로부터 ‘Got error 24’와 같은 에러 메시지를 보게 될 것이다. 이때는 open_files_ limit 값을 늘려줘야 한다. – 한 테이블당 서브파티션(subpartition)을 포함해 파티션의 최대 개수는 1,024개이다.

효과적인 사용은 사용자의 몫

데이터가 점점 더 대용량화되는 가운데 MySQL도 늦게나마 이런 특징들을 지원하기 시작했다. 아직까지 부족한 점도 많지만 MySQL은 끊임없이 발전하고 있고 이를 잘 활용하기 위한 기법들이 많이 소개되고 있으므로 단순히 이를 Oracle과 같은 상용 DBMS와 비교하는 것은 별 의미가 없다. MySQL은 나름의 영역에서 다양한 기능과 좋은 성능을 내 주고 있으며 어떤 서비스에 어떻게 사용할지는 사용자들의 몫이다. MySQL과 같은 오픈소스 DBMS가 한층 더 좋은 모습으로 나타날수록 사용자 입장에서는 반갑고 고맙기 그지없을 뿐이다.

참고자료 1. http://dev.mysql.com/doc/refman/5.1/en/partitioning.html 2. http://dev.mysql.com/tech-resources/articles/mysql_5.1_partitioning_with_dates.html 3. http://dev.mysql.com/tech-resources/articles/mysql_5.1_partitioning.html 4. http://dev.mysql.com/tech-resources/articles/testing-partitions-large-db.html

iBoot + MultiBeast: Install Mac OS X on any Intel-based PC

BEFORE YOU BEGIN

• If you have greater than 4gb of RAM, remove the extra RAM for a maximum of 4gb. You can put back any extra RAM in after the installation process.
• Use only 1 graphics card in the 1st PCIe slot with 1 monitor plugged in.
• Remove any hard drives besides the blank drive being used for OS X.
• Remove any USB peripherals besides keyboard and mouse.
• Remove any PCI cards besides graphics- they may not be Mac compatible.
• If using a Gigabyte P55 board, use the blue Intel SATA ports- not the white Gigabyte SATA ports.
• It’s best to use an empty hard drive- you will have to partition and format the drive.
• Always back up any of your important data.

STEP 1: BIOS SETTINGS
You will need to set your BIOS to ACHI mode and your Boot Priority to boot from CD-ROM first. This is the most important step, and one many people overlook. Make sure your bios settings match these. It’s not difficult- the only thing I did on my Gigabyte board besides setting Boot Priority to CD/DVD first was set Optimized Defaults, change SATA to AHCI mode, and set HPET to 64-bit mode.

STEP 2: INSTALL MAC OS X
In order to boot the Mac OS X Retail DVD, you’ll need to download and burn iBoot. For desktops and laptops using unsupported Intel CPUs and graphics, a legacy version of iBoot can be downloaded here.

1. Download iBoot
2. Burn the image to CD
3. Place iBoot in CD/DVD drive
4. Restart computer
5. At Chameleon prompt, eject iBoot
   
6. Insert your Mac OS X Snow Leopard Retail DVD and press F5
7. When you see the screen below, press enter to begin the boot process

1. When you get to the installation screen, open Utilities/Disk Utility
2. NOTE: If you can’t get to the installation screen, retry the process, but type -x at the screen above. This will enter Mac OS X Safe Mode, which will allow you to proceed.
3. Partition your hard drive to GUID Partition Table
4. Format your hard drive to Mac OS Extended (Journaled)
5. For the purposes of this guide, name it Snow Leopard. You can rename it later.
6. Close Disk Utility
7. When the installer asks you where to install, choose Snow Leopard
8. Choose Customize‚ and uncheck additional options. This will hasten the install process. You can always install this stuff later.
9. Restart computer.
10. Place iBoot back in drive.
11. When you get to the Chameleon boot selection screen, choose your new Snow Leopard installation.

1. View the super-cool Mac OS X Snow Leopard Welcome Video, and set up your computer!

STEP 3: UPDATE TO 10.6.5
Upon the release of 10.6.2 and the 27″ Intel Core i5 and i7 iMacs, Mac OS X Snow Leopard officially supports the Core i5 750 and Core i7 860. The 10.6.5 Update will install a Vanilla Kernel, as well as a host of security and stability fixes. Details are available on Apple’s website.

1. Open Finder and navigate to your Snow Leopard drive.
2. Right-click and delete Mac OS X Install Folder. This folder is an unnecessary remnant of the installation process, and serves no purpose.
3. Download the Mac OS X 10.6.5 Combo Update
4. Download MultiBeast
5. Open MultiBeast- don’t run it yet, just leave it open. Set up windows as shown.

1. Mount MacOSXUpdCombo10.6.5.dmg
2. Install MacOSXUpdCombo10.6.5.pkg
3. Upon completion, the installer will ask you to reboot. DO NOT REBOOT.
4. Switch to the already open MultiBeast. If it closes, just re-open it.

STEP 4: MULTIBEAST

MultiBeast is an all-in-one post-installation tool designed to enable boot from hard drive, and install support for Audio, Network, and Graphics. It contains two different complete post-installation solutions: EasyBeast and UserDSDT. In addition it includes System Utilities to rebuild caches and repair permissions and a collection of drivers, boot loaders, boot time config files and handy software.

Choose one of the following options directly following a fresh installation and update:

EasyBeast is a DSDT-free solution for any Core/Core2/Core i system. It installs all of the essentials to allow your system to boot from the hard drive. Audio, Graphics and Network will have to be enabled separately.

UserDSDT is a bare-minimum solution for those who have their own pre-edited DSDT. Place your DSDT.aml on the desktop before install. Audio, Graphics and Network will have to be enabled separately. HINT: Check the DSDT Database for a pre-edited DSDT.

1. Run MultiBeast.
2. If you have a custom DSDT that’s been edited, place the file on your desktop and choose UserDSDT.
3. All others select EasyBeast
4. Select System Utilities.
5. Optionally, you may install further drivers via Advanced Options to enable ethernet, sound, graphics, etc… Be sure to read the documentation provided about each installation option. NOTE: EasyBeast, and UserDSDT install Chameleon RC4 by default, so you’ll not need to check that option.

1. Install to Snow Leopard- it should take about 4 minutes to run scripts.
2. Eject iBoot.
3. Reboot- from your new Snow Leopard installation drive.

Congratulations! You’re done!!

Your PC is now fully operational, while running the latest version of Mac OS X Snow Leopard! And you have a nice Boot CD to get into your system in case things go awry. Boot your system from iBoot if you have issues. You may run MultiBeast as often as you like.

If you can’t boot, try typing -x at the Chameleon prompt to enter safe mode, or just boot with iBoot. When you get to the desktop, you can make all of the changes you need to. The best way to start fresh is delete whatever you’re trying to get rid of- including the whole /Extra folder, as most kexts are installed there. Then you can re-run MultiBeast. As long as you rebuild caches and repair permissions after you’re done, you can do just about anything you want to /Extra/Extensions and /System/Library/Extensions. Anything can be tweaked and enabled upon subsequent uses of MultiBeast.

If you’ve had success using iBoot + MultiBeast, consider a contribution to help keep the sites going. We’re constantly updating and tweaking our tools to help you.

Thanks in advance!

-tonymacx86 & MacMan

PS: For our most current workarounds and solutions for issues such as USB and audio, check out the Mac OS X 10.6.3 Update, Mac OS X 10.6.4 Update, and Mac OS X 10.6.5 Update articles. Good luck, and see you on the forum!

출처 : 토니맥

• WorkFlow – WorkFlow.doc
• WorkTable – WorkTable.xls
• 일정관리 – Schedule.xls, Schedule2.xls, Schedule3.xls
• 작업일정표 – 작업일정표.xls
• WSG(웹 스타일 가이드) – WSG-CAU.ppt, WSG-SKT.doc, WSG-YONSEI(Link)
• 스토리보드
  1. 스토리보드.관리자.PMS.ppt – 웹기반의 업무용시스템 개발을 위한 스토리보드
  2. 스토리보드.사용자.제품홍보.ppt – 제품(솔루션) 홍보용 사용자페이지 스토리보드
  3. 스토리보드.사용자.아이헬퍼스.ppt – 아이헬퍼스사이트 사용자페이지 스토리보드
  4. 스토리보드.관리자.시스템메뉴.ppt – 웹사이트 관리자 페이지에서 사용자관리,메뉴관리등의 시스템메뉴 스토리 보드
  5. 스토리보드.사용자.시승이벤트.ppt – 기아자동차 시승이벤트 스토리보드
  6. 스토리보드.사용자.쇼핑몰.ppt – 인터넷 대형쇼핑몰 스토리보드
  7. 스토리보드.사용자.쇼핑몰(2).ppt – 인터넷 쇼핑몰 스토리보드
  8. 스토리보드.사용자.GiftShop.ppt, 스토리보드.관리자.GiftShop.ppt – 쇼핑몰(특판) 스토리보드
  9. 스토리보드.관리자.자산운용.ppt – 웹사이트(자산운용사) 관리자 페이지 스토리보드
  10. 스토리보드.WAPP.인트라넷.ppt – 회사업무용(자산관리) 인트라넷
  11. 스토리보드.WAPP.마스터페이지.ppt – 웹기반의 업무용시스템 개발을 위한 마스터 페이지 설계
• 사이트맵 – sitemap.xls
• 개발환경설정 – 개발환경설정v1.0.doc
• 표준정의서 – 표준정의서v1.0.doc
• ERD(Entity Relationship Diagram) – ERD.ER1
• 프로그램목록 – 프로그램목록v1.0.doc
• 프로그램상세설계서 – 프로그램상세설계서v1.1.doc
• 테이블상세설계서 – 테이블상세설계서v1.0.doc
• 시스템일일점검 – 시스템일일점검.doc
• 시스템주간점검 – 시스템주간점검.doc
• 장애처리보고서 – 장애처리보고서.doc
• 회의록 – 회의록v1.0.doc
• 업무협조전 – 업무협조전.doc
• 주간보고서 – 주간보고서.xls
• 월운영계획서 – 월운영계획서.xls
• 체크리스트 – 체크리스트v1.0.xls
• QA보고서 – QA보고서.xls
• 메뉴얼 – 메뉴얼-웹사이트관리자.ppt
• 검색엔진마케팅 – 검색엔진마케팅.doc
• 웹사이트 성능(로드)테스트 – 성능(로드)테스트.xls
• 인수시험결과서 – 인수시험결과서.doc
• 인수시험절차서 – 인수시험절차서.doc
• Evaluation Report – Evaluation Repor1.1.doc
• 제안서 – 개발제안서-모바일.ppt, 개발제안서-제2금융.ppt, 개발제안서-꽃배달.ppt, 개발제안서-모바일도서관.ppt, 사업제안서-게임.ppt, 사업제안서-SMS(Next).ppt, 사업제안서-광고.ppt
• 운영업무정의
  1. 운영업무정의-SE.doc – 시스템 관리 및 시스템 엔진니어 업무정의
  2. 운영업무정의-DB.doc – Database(Oracle) 운영업무 정의
  3. 운영업무정의-Back.doc – 웹사이트 백오피스(관리자 시스템) 업무정의
  4. 운영업무정의-Front.doc – 웹사이트 사용자 페이지의 기획 및 디자인등의 업무정의
• 인력관리 – 이력서.doc, 인사카드.xls, 프로파일.doc

출처: http://www.ihelpers.co.kr

RAID란?

과거 대용량 디스크가 고가였던 시절, 여러개의 디스크를 하나로 묶어 대용량처럼 사용하는 기술
100GB이상의 대용량 디스크가 가정에서도 쉽게 사용되고 있지만, 스토리지에서 흔히 사용되는
TB단위의 대용량의 데이터가 필요로 하는 현대사회에서 꼭 필요한 기술이다.

예전에는 대용량 HDD 와 RAID 장비가 고가여서 기업용 서버에서 주로 사용되었지만 요즘은 가격이 많이내려 사설 서버나 개인용 서버에도 많이 쓰인다.

RAID의 사용

1. 여러개의 디스크를 하나의 대용량 디스크처럼 사용.
2. 여러개의 디스크 데이터를 나누어 한꺼번에 쓰고 한꺼번에 읽어 IO속도를 높임.
3. 하나의 디스크에 장애가 생기더라도 데이터를 살리기위한 미러링(백업) 역할.

RAID의 종류

- RAID0 (스트라이핑)
1개의 데이터를 여러개의 하드에 분산해서 저장하는 방식이다.
물론 1개의 하드에 저장했을때보다 빠르게 읽어 들일수 있지만
하나의 디스크에서 장애가 생기면, 이 모든 데이터를 잃는 위험부담.
- RAID1(미러링)
RAID0의 기법에 미러링(거울) 방식을 적용한 기법이다.
1개의 데이터를 여러개의 하드에 분산하여 저장하되, 한번 쓸 때 두개의 디스크에 같은내용을

기록 100GB 디스크 10개를 이용하여 500GB를 사용한다.
디스크에 장애가 생기면 미러링된 데이터를 읽어옴.

- RAID2(hamming)
RAID level 2는 에러검출능력이 없는 드라이브를 위해 hamming 오류정정코드를 사용한다.

모든 SCSI 드라이브는 에러검출능력을 갖고 있기 때문에 SCSI 드라이브를 사용할 경우 이

레벨은 별로 쓰이지 않는다.

※ 현재 사용되지 않음

- RAID3(패리티)
패리티 정보를 저장하고, 나머지 드라이브들 사이에 데이터를 바이트 단위로 분산한다.

이것은 level 4와 유사하나 바이트 단위의 분산 저장을 경제적으로 수행하기 위해선 하드웨

어적인 지원이 필요하다.

※ 현재 사용되지 않음
- RAID4 (패리티)
RAID1은 디스크의 용량을 절반밖에 활용할수 없어서 비싸다 그래서 고안된기술로
데이터를 분산 저장하고, 데이터들을 특정 연산후 결과값을 별도의 공간(페리티 디스크)에

저장한다.
그리하여 디스크에 장애가 생기면, 페리티디스크에 있는 데이터를 이용해 복구가 가능함.
하지만 두개이상의 디스크에 동시장애가 생기면, 복구 불가
동시에 많은양의 데이터가 연산될때, 병목현상이 생김.
- RAID5 (스트라이핑 + 패리티)
병목현상을 해결하기 위해서 나온 것으로 현재까지 세계적으로 가장 많이 사용된다.
별도의 패리티 디스크를 가지고 있지 않고, 모든 패리티 데이터를 데이터 디스크에 분산

저장한다.
하지만, 디스크를 추가할때 모든 데이터에 대한 패리티 데이터를 다시 연산해야함으로 확장이

어렵다.

- RAID6(스트라이핑 + 패리티)
RAID5와 비슷하지만, 페리티 정보를 모든 디스크에 저장. 두개의 디스크에 장애가 발생하여도

복구가 가능하며, 읽기 성능이 우수하지만, 패리티를 여러번 갱신해야 하기 때문에 속도가 느림.

디스크를 재구성하는 동안 성능 저하가 될수 있음.

- RAID7

Optimized Asynchrony for High I/O Rates as well as High Data Transfer Rates

이 형식은 컨트롤러로서 내장되어 있는 실시간 운영체계를 사용하며, 속도가 빠른 버스를

통한 캐시, 독자적인 컴퓨터의 여러 가지 특성들을 포함하고 있다

- RAID53

High I/O Rates and Data Transfer Performance

이 형식은 각 스트립은 RAID-3 디스크 에레이인 스트립 어레이를 제공한다.

이 방식은 RAID-3보다 높은 성능을 제공한다
- RAID10 (미러링+스트라이핑)
RAID1 로 묶은 쌍을 RAID0 로 합한 것이다. RAID 중 가장 좋은 방식이다.

RAID10 은 RAID1 로 묶인 HDD 2개가 동시에 Error 나지 않는한 데이타는 안전하다.

따라서 RAID0+1 보다 더욱 안전한 방식이다.

- RAID0+1(스트라이핑+미러링)

RAID0 로 합한 2쌍을 RAID1 로 묶은 것이다. RAID10 보다 안정성이 떨어진다.
RAID0+1 은 RAID1 로 묶인 2개의 RAID0 에서 동시에 Error 나면 전체 데이타를 읽어버린다.

RAID5 와 RAID6의 차이

내부적인 기술의 차이는 있지만 RAID6는 RAID5의 확장 개념으로 보아도 무방하다. RAID5가 5개의 HDD를 장착하고 하나의 HDD가 fail 나더라도 복구가 가능한 데이터 신뢰도를 제공하는데 반하여, RAID6는 6개의 HDD를 장착하고 두 개의 HDD가 동시에 fail 나더라고 복구가 가능해 우수한 데이터 신뢰도를 보장한다.

RAID5는 최소 3개의 HDD가 구성이 되어야 RAID5 레벨 설정이 가능하고, RAID6는 최소 4개의 HDD가 구성이 되면 RAID6 레벨 설정이 가능하다. 물론, RAID6 에 따른 데이터 신뢰도는 상승하는 반면, 구성 가능한 용량은 RAID5 보다 상대적으로 적을 수밖에 없다. 다만, 그 차이가 데이터 신뢰도를 생각하면 무시하여도 무방할 정도라 할 수 있다.

용량으로 따져본다면 8채널 구성의 경우 RAID0이 설치한 하드디스크를 모두 사용해 250GB 구성시 총 2008GB이 가능했으며, RAID5는 하나 분량의 용량을 패리티 체크 용도로 사용해 1757GB이 가능, RAID6는 두 개 분량의 용량을 패리티 체크 용도로 사용해 1506GB를 전체용량으로 사용할 수 있다.