저도 그누보드 첨 보고 data/session으로 넣어둔 이유를 한참 생각했더랬습니다.
퍼미션 관련한 여러 문제를 data 디렉토리로 일괄처리하려고 첨에 생각했겠지.. 하는 추측 뿐이었는데.
data 경로는 생각해보니 웹 접근이 자주, 공개적으로 되어야 할 디렉토리기때문에 좀 문제가 있겠네요.
아무리 프로그램으로 파일명을 변경한다 해도 그렇게 하면 문제가있을테니까요.
제가 생각하기에, 만일 /tmp로 사용하더라도 문제가 되는것은, 공개된 보드 소스가 호스팅에서 사용될 때, 호스팅 회사에서 세션관리를 해야하는 경우가 생길 수 있겠네요.. 각 유저별로 세션관리가 어렵게 되겠죠. 초보자에겐 문제의 원인을 찾기 힘들어지는 경우도 될 수 있겠습니다.

시스템 기본 세션 경로는 웹에서 접근이 안되니 괜찮을듯 합니다.
서버에  DB세션을 적용한적이 있는데 DB부하로 잠깐 사용하고 내렸던적이 있습니다.

맘고생좀 하셨겠네요 ^^

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ앜ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
뿜었어요 ㅠ

아 ㅋㅋㅋㅋ 뿜었다 ㅋㅋㅋ 관리자님 대박 ㅋㅋㅋ

흠.. 부하가 insert or update 에서 테이블락 거는 곳에서 생길거 같아요.

뭐 인덱스 잘 주실거 같고 table의 저장형을 innoDB 로 바꿔서 다시 시도해 보시는게 어떨까요?
(myisam은 table단위 lock, innodb는 row단위 lock)

그리고 저 같은 경우는 부하가 생기는 코드가 있을 때 javascript 요청으로 분리해 버립니다. 이 방법도 써보셔요.

db세션으로 부화 없이 하는 방법을 생각하는게 저는 더 좋을것같습니다.
일단 data 세션으로하면 세션삭제가 잘안되서 오래 유지했을대
자동 백업 돌려놓으면 백업때문에 부화가 더 심해지더라구요 오래 유지 될경우에요

만남주선대행 사이트 http://bit.ly/IoZcsW

헐 ㅋㅋㅋㅋ

아 ㅋㅋㅋ 지운아빠님때문에도 뿜음 ㅋㅋㅋ

사용자가 많은 사이트에서 디비에 session 거는거는 비추입니다.
(db에 조금이라도 무리가 가능 상황이 생기면, db세션과 시너지를 일으켜서 db를 뻗게 만들어버립니다. 특히 myisam 은 절대 db세션 쓰면 안됩니다.)

memcached 로 세션관리하는걸 추천드립니다.
L4 로드밸란서 없이 웹서버를 이중화 하는 경우에도 memcached가 db방식보다 훨씬 안정적입니다.

배포판 그누보드 때문이라면, 파일 기반으로 세션 핸들러를 만드셔야 할것 같네요. 깊이 생각할수록 어려워지는 문제네요.

동접 1,500~2,000 정도 되는 사이트에 DB방식을 테스트 하였다가ㄷㄷ 기겁하고는 이전 data/session 방식으로 되돌려 버렸습니다.ㅠ

중간 이상 사이트 같은경우는 제반사항도 어느정도 갇춰져야되기때문에
sir정도 사이트기준으로 그누원본작업을 하시면안될것같은데요
서버단도 같이 갇춰져야되는 문제라서요
db셀렉트가 부화가 심한것은 어차피 그누에서는 config 나 board 도 페이지 이동때마다
호출하기때문에 큰사이트 같은경우는 config 나 board 만 배열 처리 해도 속도는
빨라질것으로 보여요

그누규모의 사이트는 DB세션 안됩니다...ㅠㅠ

부하가 얼매나 많이 걸리는데요....그냥 파일세션으로 해도 됩니다.....

DB 세션 할려면, 돈을 엄청시리 투자 해야 합니다.....

저는 그냥 파일세션에 추천 한표.....

DB session을 이용하기 딱 알맞은 규모는 100명 이내가 딱입니다...

사실 DB session은 세션 관리 기법중의 하나정도라고 알고 있는게 맞습니다....

DB session을 실전에 이용한다는건 사실 빈대 잡을려고 초가삼간 다 태우는 격이랑 비슷한듯...

득보다는 실이 훨씬 큽니다....

그럼..백섭 해주실 건가요??

램을 추가하셔서 heap 메모리로 올리는건 어떻게 생각하시는지요 =_=
파일 세션은 원래 웹 경로에 노출되면 안되는데 말이죠 ;; ㅠㅠ

동접자 5천명 이상 사용시 캐시 파일과 세션 파일은

memcache 나 램디스크에 올리면 됩니다

서버단을 수정할수 없으므로!
/tmp 보내 버리시면 될거 같습니다!

또는 디비 세션 파일 세션 사용 어느걸 사용할건지 체크박스 고고싱

/tmp로 보내면 문제 생겼던건 계정 뚫리고 나서 생겼던 문제 외엔 없었습니다.

/tmp는 777이기 때문에 실행 권한도 들어가서 가끔 디렉토리 숨겨놓고 perl스크립트 돌리는 경우도 있더라구요 -_-;; udp로 뭐가 자꾸 나간다고 해서 서버 확인해보니 tmp에서 뭔가가 돌아가더군요 ㅋㅋㅋㅋㅋㅋ

업데이트 기다리고 있겠습니다.
저도 리자님따라 db세션 안쓸라구요. ^^
괜히 혼자 수정했다가 뻑날까 겁나서요. ㅋㅋㅋ

전 예전에 동접 천명이상에서 그누로 DB세션 썼었는데 아무문제 없었는데 말이져;

http://code.google.com/p/zebra-session/

제 소견에서는 크게 달라보이지 않는데 zebra-session으로 관리하면 부하가 덜 심한가요?

음.. 사용중인 사이트에 적용해볼수도 없구.. 궁금하네요.. @@ 사용해보신분 후기좀.ㅠ,.ㅠ

그런가요. 짐작이지만, 위에서 나온 문제점을 극복하지 못했다면 zebra session이 저렇게 소개 되지는 않을 듯해서요.

참고로 남겨둡니다.
[공유메모리에 session 저장하기]
http://palma-seo.com/php-session-setup-example-using-memory-configuring-subdomains