Tuning database innodb diatas 1 jt record
dedy setiawan
untuk tuning database innodb dengan record diatas 1 jt bagaimana?
soalnya saya mengalami kendala aplikasi berjalan sangat lambat untuk reporting.
memang kalau menggunakan tabel myisam query berjalan cepat.
tetapi karena tabel transaksi menggunakan innodb jadi harus bagaimana trik tuningnya.
ditunggu info nya bagi yang pernah mengalami kendala seperti kasus diatas
terima kasih
dedy setiawan
gowar gowar
sekarang sudah lebih cepat karena servernya (hardware) diupgrade
--
Untuk memposting, silakan reply email ini atau kirim email baru ke alamat: mysql-i...@googlegroups.com
Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat: mysql-indones...@googlegroups.com
Untuk melihat arsip milis, member, atau hal-hal lainnya silakan kunjungi alamat: http://groups.google.com/group/mysql-indonesia?hl=id
Eko Kurniawan Khannedy
sekarang sudah lebih cepat karena servernya (hardware) diupgrade
--
Eko Kurniawan Khannedy
Mahasiswa UNIKOM (Universitas Komputer Indonesia)
blog : http://eecchhoo.wordpress.com/
email : khannedy[at]gmail.com
phone : +6285292775999
Ryan Fabella
sharing dong konfigurasi hardware dan my.cnf nya....
2010/1/15 Eko Kurniawan Khannedy <echo.k...@gmail.com>:
> --
> Untuk memposting, silakan reply email ini atau kirim email baru ke alamat:
> mysql-i...@googlegroups.com
> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat:
> mysql-indones...@googlegroups.com
>
> Untuk melihat arsip milis, member, atau hal-hal lainnya silakan kunjungi
> alamat: http://groups.google.com/group/mysql-indonesia?hl=id
>
--
Salam Hormat
Ryan Fabella
sta anto
eRQee
(siapkan secangkir kopi dan popcorn, nunggu balesan GoWar) ^_^
--
Salam Hormat,
Rizky Prihanto
Chief of Software Architect @ PT Cinox Media Insani
Phone #1: 0812 535 22 392
Phone #2: 022 3028 3329
gowar gowar
ga ada tuning apa2, di my.cnf juga standar. pokoknya kalo reporting langsung ngambil dr tabel yg gede itu kagak bakal jln (seperti yg sebelumnya digunakan). maka akhirnya kita bikin tabel yg isinya summary dari table yg gede bgt itu. kekurangannya ya data di reportnya jd ga realtime.
sebenarnya pengen tuning siy tp blm dpt caranya. sorry ga bisa posting file my.cnf karena emang ga ada yg special.
eRQee
dan supaya realtime, bisa aja dibuat mekanisme trigger after insert/update/delete di tabel gemuk itu tadi supaya nge-update tabel summary tersebut. atau bikin mysql events untuk "meremajakan" data di tabel summary pada jam-jam idle dengan interval terserah (harian/mingguan/bulanan).
untuk my.cnf supaya innodb bisa jalan optimal, mungkin elo bisa sedikit melirik rumput tetangga berikut ini: http://www.bigdbahead.com/?p=115
atau liat hasil riset orang tentang konfigurasi InnoDB di sini: http://www.tag1consulting.com/InnoDB_Performance_Tuning
*lho, popcorn gw siapa yg makan?
--
Salam Hormat,
Rizky Prihanto
Chief of Software Architect @ PT Cinox Media Insani
Phone #1: 0812 535 22 392
Phone #2: 022 3028 3329
gowar gowar
saya masih ada tabel satu lagi sebut saja table request yg, yg dipake buat nyimpen data datetime kapan harus undate tabel summary.
jadi begitu ada user yg ngebuka reportnya otomatis insert ke table request itu.
tapi tetep masih blm sanggup kl harus realtime, soalnya untuk ngupdate summarynya pun cukup makan waktu dan resource, pasti mengganggu proses utama dari sistem saya.
buat om eRQee, tks linknya..
gowar
Ponco Nugrah Wibowo
ukuran datax smpe gede gak brpengaruh smpe lambat,,trmsuk optimasi &
efektivitas queryx,,q dh prnh coba upgrade hardware trnyata gak ad
efekx te2p msh lemot, trus dianalisa trnyata yg develop programx
ngawur utk desain databasex + vendorx gak brtanggung jwb,,mgkn solusi
laen konsep clustering pake mysql-cluster, utk tuning q prnh pake tool
MySQLTuner (sourcex kykx pake perl dech) n jgn lupa dperhitungkn
resourcex trmsuk memory yg dpake..
On 1/15/10, gowar gowar <dari...@gmail.com> wrote:
> yup betul sekali om..
>
> saya masih ada tabel satu lagi sebut saja table request yg, yg dipake buat
> nyimpen data datetime kapan harus undate tabel summary.
> jadi begitu ada user yg ngebuka reportnya otomatis insert ke table request
> itu.
> tapi tetep masih blm sanggup kl harus realtime, soalnya untuk ngupdate
> summarynya pun cukup makan waktu dan resource, pasti mengganggu proses utama
> dari sistem saya.
>
> buat om eRQee, tks linknya..
>
> gowar
>
> 2010/1/15 eRQee <qve...@gmail.com>
>
>> itu ide bagus untuk mengekstraksi data dari tabel gemuk ke tabel summary
>> supaya mempercepat query buat report.
>>
>> dan supaya realtime, bisa aja dibuat mekanisme trigger after
>> insert/update/delete di tabel gemuk itu tadi supaya nge-update tabel
>> summary
>> tersebut. atau bikin mysql events untuk "meremajakan" data di tabel
>> summary
>> pada jam-jam idle dengan interval terserah (harian/mingguan/bulanan).
>>
>> untuk my.cnf supaya innodb bisa jalan optimal, mungkin elo bisa sedikit
>> melirik rumput tetangga berikut ini: http://www.bigdbahead.com/?p=115
>>
>> atau liat hasil riset orang tentang konfigurasi InnoDB di sini:
>> http://www.tag1consulting.com/InnoDB_Performance_Tuning
>>
>> **lho, popcorn gw siapa yg makan?*
>>
>>
>>
>> --
>> Salam Hormat,
>>
>> *Rizky Prihanto*
>> Chief of Software Architect @ PT Cinox Media
>> Insani<http://www.cinox.co.id/>
>> Phone #1: 0812 535 22 392
>> Phone #2: 022 3028 3329
>> [image: Blogger] <http://rizky.prihanto.web.id>[image:
>> Facebook]<http://www.facebook.com/erqee>[image:
>> Twitter] <http://www.twitter.com/erqee>[image:
>> Friendster]<http://www.friendster.com/erqee>[image:
>> Linkedin] <http://www.linkedin.com/in/erqee>[image:
>> Tumblr]<http://erqee.tumblr.com>
>>>>> > mysql-indones...@googlegroups.com<mysql-indonesia%2Bunsu...@googlegroups.com>
>>>>> >
>>>>> > Untuk melihat arsip milis, member, atau hal-hal lainnya silakan
>>>>> kunjungi
>>>>> > alamat: http://groups.google.com/group/mysql-indonesia?hl=id
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Salam Hormat
>>>>>
>>>>> Ryan Fabella
>>>>>
>>>>> http://zer0d4y.blogspot.com/
>>>>>
>>>>> --
>>>>> Untuk memposting, silakan reply email ini atau kirim email baru ke
>>>>> alamat: mysql-i...@googlegroups.com
>>>>> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat:
>>>>> mysql-indones...@googlegroups.com<mysql-indonesia%2Bunsu...@googlegroups.com>
>>>>>
>>>>> Untuk melihat arsip milis, member, atau hal-hal lainnya silakan
>>>>> kunjungi
>>>>> alamat: http://groups.google.com/group/mysql-indonesia?hl=id
>>>>>
>>>>
>>>>
>>>> --
>>>> Untuk memposting, silakan reply email ini atau kirim email baru ke
>>>> alamat: mysql-i...@googlegroups.com
>>>> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat:
>>>> mysql-indones...@googlegroups.com<mysql-indonesia%2Bunsu...@googlegroups.com>
>>>>
>>>> Untuk melihat arsip milis, member, atau hal-hal lainnya silakan kunjungi
>>>> alamat: http://groups.google.com/group/mysql-indonesia?hl=id
>>>>
>>>
>>>
>>> --
>>> Untuk memposting, silakan reply email ini atau kirim email baru ke
>>> alamat:
>>> mysql-i...@googlegroups.com
>>> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat:
>>> mysql-indones...@googlegroups.com<mysql-indonesia%2Bunsu...@googlegroups.com>
>>>
>>> Untuk melihat arsip milis, member, atau hal-hal lainnya silakan kunjungi
>>> alamat: http://groups.google.com/group/mysql-indonesia?hl=id
>>>
>>
>>
>> --
>> Untuk memposting, silakan reply email ini atau kirim email baru ke alamat:
>> mysql-i...@googlegroups.com
>> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat:
>> mysql-indones...@googlegroups.com<mysql-indonesia%2Bunsu...@googlegroups.com>
Endy Muhardin
> dear all,
>
> untuk tuning database innodb dengan record diatas 1 jt bagaimana?
> soalnya saya mengalami kendala aplikasi berjalan sangat lambat untuk
> reporting.
> memang kalau menggunakan tabel myisam query berjalan cepat.
> tetapi karena tabel transaksi menggunakan innodb jadi harus bagaimana trik
> tuningnya.
Tuning itu gampang.
Yang sulit dan lama itu profiling, yaitu menemukan bottleneck.
Sekali bottleneck ditemukan, google 5 menit juga ketemu cara tuningnya.
Berikut metodologi saya dalam melakukan profiling :
1. Jalankan aplikasi dengan stress test tool, misalnya Apache JMeter.
2. Selama stress test sedang jalan, login ke mysql dan jalankan show
processlist berkali-kali.
Nanti akan keliatan query mana yang makan waktu lama.
3. Pilih query yang waktunya paling besar.
4. Jalankan explain select untuk query tersebut untuk melihat
bagaimana MySQL menjalankan query tersebut.
http://dev.mysql.com/doc/refman/5.0/en/explain.html
5. Lakukan tuning yang sesuai, misalnya:
- tambahkan index di kolom2 yang sering dipakai di where dan order by
- samakan tipe data dan length untuk kolom2 yang sering dijoin
- ubah urutan join
- perbaiki query-nya di source code aplikasi
6. Kembali ke #1 dan lakukan terus sampe performance-nya acceptable.
Gak perlu kenceng, yang penting acceptable.
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --
Ryan Fabella
pakai opsi slow query bisa mengetahui dari hasil stress test.
2010/1/15 Endy Muhardin <endy.m...@gmail.com>:
> --
> Untuk memposting, silakan reply email ini atau kirim email baru ke alamat: mysql-i...@googlegroups.com
> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat: mysql-indones...@googlegroups.com
>
sta anto
Adhari C Mahendra
Bicara tuning memang menarik, kalau kata Endy bisa diselesaikan dalam 5 menit itu sangat memungkinkan. Yang paling penting adalah ada beberapa hal yang harus diberikan dalam masalah tuning (tidak hanya di DB, juga di APP atau OS).
Yang paling utama adalah scope dari tuning, jadi perlu di define scopenya, kalau tidak tuning menjadi pekerjaan yang tidak akan pernah selesai. Scope ini umumnya di drive dari prespektif bisnis.
Sebagai misal, kasus mas Dedy Setiawan, yang jadi pertanyaan, apakah report harus realtime dan akurat? Atau hanya dijadikan indikator saja. Kalau cuma dijadikan indikator, maka solusi mirroring bisa dijalankan, master pakai InnoDB, slave pakai MyISAM (kebetulan sudah tahu jalan keluarnya, yaitu MyISAM cepat).
Kalau memang requirementnya berbeda dengan yang diatas ada beberapa item yang bisa digunakan untuk tuning InnoDB:
- Buat partisi (sejak versi 5 kalau tidak salah) InnoDB di MySQL sudah support partisi, ada baiknya lokasi Index dan Data ditaruh di spindle yang berbeda data path dan controllernya, dan data yang dipartisi juga di taruh di spindle yang berbeda data pathnya (ini kondisi ideal, namun refer ke kata Endy, kita harus tahu bottlenecknya).
- InnoDB buffer, coba dimainkan
- Design table seperti yang disampaikan Endi, nah kalau anda menggunakan MySQL yang baru yang sudah support SMP, maka ada baiknya master tables dan detail table disimpan di partisi yang berbeda (refer ke note no 1 diatas, maka diharapkan bisa concurrent query).
- Coba explore http://dev.mysql.com/doc/refman/5.4/en/innodb-tuning.html atau tips dari http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ dan saya yakin masih banyak parameter lagi yang bisa dimainkan
Sebagai hint, umumnya problem performance itu ada di Aplikasi makanya ada baiknya review query terkadang berakibat merubah design DB.
Mungkin ketelanya masih sedikit dulu, lain kali cari yang lebih mengenyangkan... :D
On 1/18/10 8:21 AM, "sta anto" <setian...@gmail.com> wrote:
enak nih popcorn kakakakak
Dedy Handriyadi
haha..
ga ada tuning apa2, di my.cnf juga standar. pokoknya kalo reporting langsung ngambil dr tabel yg gede itu kagak bakal jln (seperti yg sebelumnya digunakan). maka akhirnya kita bikin tabel yg isinya summary dari table yg gede bgt itu. kekurangannya ya data di reportnya jd ga realtime.
Warm Regards,
Dedy Handriyadi
Endy Muhardin
>
> 2010/1/15 gowar gowar <dari...@gmail.com>
>>
>> haha..
>> ga ada tuning apa2, di my.cnf juga standar. pokoknya kalo reporting
>> langsung ngambil dr tabel yg gede itu kagak bakal jln (seperti yg sebelumnya
>> digunakan). maka akhirnya kita bikin tabel yg isinya summary dari table yg
>> gede bgt itu. kekurangannya ya data di reportnya jd ga realtime.
>>
>
> ya, setuju ama yang ini, cuma 'ga realtime'-nya itu yang kadang bikin
> jengkel client hahahahahaa...
Ini sebetulnya urusannya psikologis, bukan teknis.
Selain harus bisa tuning aplikasi, kita juga harus bisa tuning
ekspektasi client.
Pengalaman saya, ada satu report yang butuh waktu lama tiap kali dijalankan.
Soalnya datanya besar dan untuk menampilkannya butuh komputasi yang lumayan.
Makin besar datanya makin lemot, dan kadang2 sampe keluar out of memory error.
Lalu saya tawarkan ke client, pilih mana realtime tapi tiap klik
nunggu 3 menit (3 menit adalah waktu yang lama, cobain deh).
Atau setelah klik, < 1 detik report muncul tapi delay 1 hari, karena
saya pake scheduler untuk generate summary table tiap malam.
Akhirnya client dengan gembira menerima solusi kedua.
--
dedy setiawan
saya simpulkan cara yang efektif
1. buat tabel summary yang di tempel ke proses tertentu atau pake sheduling
2. index tabel seperti stepnya mas endy (mantap)
3. setting my.cnf ( tapi kayaknya imbasnya gak banyak)
4. nego client biar lebih fair kayaknya reasonable
5. faktor syntax sql query udah diminimalis karena udah di tune sebelum di rilis dengan dummy data
terima kasih atas masukannya
dedy setiawan
Feris Thia
Lalu saya tawarkan ke client, pilih mana realtime tapi tiap klik
nunggu 3 menit (3 menit adalah waktu yang lama, cobain deh).
Atau setelah klik, < 1 detik report muncul tapi delay 1 hari, karena
saya pake scheduler untuk generate summary table tiap malam.
Akhirnya client dengan gembira menerima solusi kedua.
--
Thanks & Best Regards,
Feris Thia
Business Intelligence Consultant
PT. Putera Handal Indotama
Phone : +6221-30119353
Fax : +6221-5513483
Mobile : +628176-474-525
http://www.phi-integration.com
http://pentaho.phi-integration.com