Re: [tanya-jawab] sorry oot soal DB nih
On 6/6/06, Mirza Khadnezar [EMAIL PROTECTED] wrote: 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. Kalo bottleneck di IO justru karena query belum optimal. Table2 nya belum diindex secara tepat. Coba di aktifkan log slow query nya. Query yang lambat tsb diteliti. 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. Ini sih masih kacang goreng... 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. Dicoba dulu aja pakai raid, supaya IO nya terbagi rata. -- 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
Re: [tanya-jawab] sorry oot soal DB nih
bisa bantuin terangin cara optimalinnya lagi ? karena ini udah mentok optimalnya mungkin ada yang kurang thx On 6/7/06, m Ilhami [EMAIL PROTECTED] wrote: On 6/6/06, Mirza Khadnezar [EMAIL PROTECTED] wrote: 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. Kalo bottleneck di IO justru karena query belum optimal. Table2 nya belum diindex secara tepat. Coba di aktifkan log slow query nya. Query yang lambat tsb diteliti. 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. Ini sih masih kacang goreng... 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. Dicoba dulu aja pakai raid, supaya IO nya terbagi rata. -- 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
Re: [tanya-jawab] sorry oot soal DB nih
On 6/7/06, Mirza Khadnezar [EMAIL PROTECTED] wrote: bisa bantuin terangin cara optimalinnya lagi ? karena ini udah mentok optimalnya mungkin ada yang kurang sudah dibaca belum? http://dev.mysql.com/doc/refman/4.1/en/optimization.html -- 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
RE: [tanya-jawab] sorry oot soal DB nih
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
Re: [tanya-jawab] sorry oot soal DB nih
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
Re: [tanya-jawab] sorry oot soal DB nih
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
[tanya-jawab] sorry oot soal DB nih
gini ada 3 server dengan traffic super super super banyak ada yang bisa bantuin selain clustering DB ? karena clustering webserver kan yah gitu ajah ( hihih macammm jagoo ajah gua padahal ga bisa :D ) nah kalau clustering DB kan ribet dan ngejelimet ada solusi gimana cara alternatifnya ? -- 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
Re: [tanya-jawab] sorry oot soal DB nih
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 ? karena clustering webserver kan yah gitu ajah ( hihih macammm jagoo ajah gua padahal ga bisa :D ) nah kalau clustering DB kan ribet dan ngejelimet ada solusi gimana cara alternatifnya ? Dicari dulu mana permasalahannya. Apa sudah yakin trafik network nya yang penuh? Analisis minimal dari output program sar dan tool network analisis traffic beberapa hal yang mungkin: * bottleneck IO solusi: - gunakan raid misalnya - SQL tuning * bottleneck CPU beli CPU, kalau perlu 8 processor + RAM 16GB :D * bottleneck network beli gigabit switch hehe. -- 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
Re: [tanya-jawab] sorry oot soal DB nih
Coba di ikuti dulu sesuai postingan bung Ilhami, bisa masalah jadi network, I/O storage atau engine database-nya. Mungkin bisa mulai di evaluasi menggunakan solusi enterprise seperti oracle. Saya pernah lihat perbandingan beberapa produk database di wikipedia dan hasil benchmark independen (googling). Atau memang mau nggak mau Anda harus membuat clustering db, ditekuni saja (siapkan formulir lemburan, kopi, teh :) Selamat ber-eksperimen. diditdr 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 ? karena clustering webserver kan yah gitu ajah ( hihih macammm jagoo ajah gua padahal ga bisa :D ) nah kalau clustering DB kan ribet dan ngejelimet ada solusi gimana cara alternatifnya ? Dicari dulu mana permasalahannya. Apa sudah yakin trafik network nya yang penuh? Analisis minimal dari output program sar dan tool network analisis traffic beberapa hal yang mungkin: * bottleneck IO solusi: - gunakan raid misalnya - SQL tuning * bottleneck CPU beli CPU, kalau perlu 8 processor + RAM 16GB :D * bottleneck network beli gigabit switch hehe. -- 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
Re: [tanya-jawab] sorry oot soal DB nih
On 6/5/06, Mirza Khadnezar [EMAIL PROTECTED] wrote: ada cara ? seperti clustering DB ? atau sejenisnya ? salah satu yg support cluster adalah Oracle Real application cluster. Dan itu untuk high availability, bukan utk membagi bandwidth -- 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
