lupa informasiin spek server ini ada sedikit cuplikan email dari salah seorang temen saya "The bottleneck is IO and the fact that MySQL only can have 1000 connections at the same time. All queries etc are optimized, so the problem is not there. We are looking into getting an even better server. The DB server that we are using right now is a real monster, dual Xeon 3 GHz processors, I think it has about 3 HD's with Raid 0+1 and 2 disks with Raid 1 running the OS.
Our server is a really hard case becase everything is very live. We have consulted huge firms that deal with scaling and optimization and they havnt been able to help us to scale in a good fashion. The solution that we are looking for right now is to get even more disks into the server to ease the IO load on each disk." **** masih menanti solusi On 6/6/06, m3 <[EMAIL PROTECTED]> wrote:
1. Hardisk dr IDE ke SCSI/SATA 2. Memory yg gede On 6/6/06, mastri <[EMAIL PROTECTED]> wrote: > Urun rembug ya, dah lama gak nulis di milsi ini. (ehm, semoga gak dianggap > memperpanjang topik OOT :) > > Mungkin bisa juga di identifikasi dari perilaku databasenya, misal: > > 1. apakah traffic yang rame itu traffic WRITE apa READ ? tipikal database > system tidak berimbang, kebanyakan sih READ nya lebih banyak daripada WRITE > nya. Kalau polanya begini, clustering mungkin agak overkill, buat aja > master-slave replication. WRITE ke master, READ nya di sebar ke semua slave. > Yang perlu identifikasi lagi, seberapa REAL TIME kebutuhan informasi nya ? > kalau harus real time ya berarti update di master harus 'transactional' di > replicate ke slave, load traffic antara master ama slave agak berat, tapi > kan bisa di buat dedicated. Pasang gigabit khusus antara master ama slave > tidak boleh ada yang lain. Kalau nggak terlalu perlu real time, boleh ada > delay, bisa di synchronize pas traffic agak longgar, misal jam 3 pagi. > Asumsi nya, traffic yang super super banyak itu tidak terjadi 24 jam sehari > 7 hari seminggu dan 365 hari setahun (atau 366 kalau tahun kabisat :). > Intinya, kenali perilaku database kita, sesuaikan solusinya. Mungkin, untuk > aplikasi seperti banking asumsi WRITE less than READ tidak berlaku ya. > Pendekatan selanjut nya lebih feasible. > > 2. kalau system nya sedemikian besar, tapi ini pendekatan dari software yang > menyimpan ke database, bukan databasenya an sich, system nya di partisi! > Maksud nya, kalau memang terlalu besar untuk menyimpan data HR dan finance > di satu tempat, kenapa tidak dipisah jadi 2 database, beda physical system > dan jaringan, dan bikin bridge aplikasi untuk menjembatani kebutuhan > referensi data. Day to day transaksi kan HR dan Finance misal nya tidak > terlalu sering saling tergantung. Kalau HR kantor pusat dan cabang terlalu > besar, kenapa tidak di pisah saja ? kalau sudah longgar, di merge. Orangkan > tidak selalu ngolah data HR kantor pusat dan cabang *berbarengan*. Partisi, > delegasikan load! Intinya, kenali perilaku system / software kita, > delegasikan load nya. Pendekatan ini agak sudah kalau system nya sudah jadi, > dan posisi kita 'cuma' DBA, tidak dalam kewenangan menentukan software > development policy > > 3. tentu saja, tool bawaan DBMS nya untuk meng identifikasi bottleneck nya > dimana fardhu atau wajib hukumnya untuk di gunakan dulu untuk tune up. > Oracle kayak nya ngasih info lengkap banget dimana saja bottle neck dari > database kita. Gak tahu yang lain . > > 4. hardware nya super super high end ? ;) kecuali kita kerja di NSA nya > amrik (no cush agency :), pokok nya tempat nongkronya dedengkot IT negeri > paman sam), asal ada dana, percaya deh, kita masih bisa upgrade hardware > kita ke level *higher* end! > > Salam, > > Tri > > -----Original Message----- > From: diditdr [mailto:[EMAIL PROTECTED] > Sent: 06 Juni 2006 11:08 > To: tanya-jawab@linux.or.id > Subject: Re: [tanya-jawab] sorry oot soal DB nih > > > Mirza Khadnezar wrote: > > ada cara ? > > seperti clustering DB ? > > atau sejenisnya ? > > > > On 6/5/06, Mirza Khadnezar <[EMAIL PROTECTED]> wrote: > >> udah dari segi H/W dah super high end server deh > >> > >> > >> On 6/5/06, m Ilhami <[EMAIL PROTECTED]> wrote: > >> > On 6/5/06, Mirza Khadnezar <[EMAIL PROTECTED]> wrote: > >> > > gini ada 3 server > >> > > dengan traffic super super super banyak > >> > > ada yang bisa bantuin selain clustering DB ? > >> > > > > > -- > FAQ milis di http://wiki.linux.or.id/FAQ_milis_tanya-jawab > Unsubscribe: kirim email ke [EMAIL PROTECTED] > Arsip dan info milis selengkapnya di http://linux.or.id/milis > > -- FAQ milis di http://wiki.linux.or.id/FAQ_milis_tanya-jawab Unsubscribe: kirim email ke [EMAIL PROTECTED] Arsip dan info milis selengkapnya di http://linux.or.id/milis
-- FAQ milis di http://wiki.linux.or.id/FAQ_milis_tanya-jawab Unsubscribe: kirim email ke [EMAIL PROTECTED] Arsip dan info milis selengkapnya di http://linux.or.id/milis
