Tanya : Performance MySql untuk Server Pulsa
kenz
Sudah 2 tahun ini saya mengelola sebuah server pulsa, awalnya database mysql hanya sekitar 1gigaan, terus tiap bulan membengkak dan sampai sekarang sudah 20 GB padahal tiap 3 bulan sudah dihapus record yang tidak terpakai.
Belakangan saya stress berat karena kinerja MySQL lambat sekali, padahal server yang digunakan adalah Xeon 4 Core 3GHz dengan Memori 6GB. Saya berkali-kali melakukan tuning mysql tapi kok belum nemu yang pas ya.
Karakter khas dari server pulsa ini yaitu :
- Memasukkan data record dengan cepat
- Database MYISAM besar
Saya pernah melakukan tuning dengan tuning-primer.sh yg didownload disini : www.day32.com/MySQL/
tapi hasilnya tetap saja sama, lambat untuk memproses data sehingga antriannya sangat banyak. berikut ini adalah my.cnf yang sekarang :
# The MySQL server
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 1024M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 6M
myisam_sort_buffer_size = 64M
thread_cache_size = 16
query_cache_size = 32M
log_slow_queries = /var/lib/mysql/mysqld_slow.log
long_query_time = 5
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
#-----Tambahan----#
skip-innodb
skip-isam
skip-bdb
skip-name-resolve
wait_timeout = 36000
max_connections = 300
max_user_connections = 250
#---------END--------#
# Replication Master Server (default)
# binary logging is required for replication
log-bin=mysql-bin
expire_logs_days = 10
# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
---------------------------------------------------------------
Pertanyaan :
1. Apakah data MYISAM yg besar 20GB adalah penyebab utamanya?
2. Bagaimana settingan my.cnf yang baik untuk karakter server pulsa?
3. Adakah solusi lain untuk mengatasi hal ini?
Mohon pencerahannya, mungkin ada yg mengalami hal yang sama. Terima kasih sebelumnya.
Salam hangat,
Kenz
Ilham Rizqi Sasmita
> Dear semua,
> Sudah 2 tahun ini saya mengelola sebuah server pulsa, awalnya database mysql
> hanya sekitar 1gigaan, terus tiap bulan membengkak dan sampai sekarang sudah
> 20 GB padahal tiap 3 bulan sudah dihapus record yang tidak terpakai.
>
Saya juga pernah lihat server pulsa yang data seharinya udah 600MB,
padahal transaksinya belum sampe 8000/hari. Ngga tau persis itu
kerjanya ngapain aja, kok bisa segede itu. Sudah begitu, pakai
replikasi Master-Slave pula yang makan bandwidth gede.
Menurut saya, MyISAM kurang cocok untuk transaction processing. InnoDB
lebih dianjurkan.
CMIIW
--
Code Is Passion
http://unitedcoders.net
rizki nanda agam
cmiiw
--
http://debian-id.org
crazy...@debian-id.org
Adhari C Mahendra
beberapa kali command DML namun harus ACID. Kalau transaksinya hanya
single insert command, maka tidak perlu membuat scope transaksi, jadi
cek sekali lagi design dan arsitektur aplikasi anda, apakah memang
membutuhkan transactional atau tidak. Oh, ya, yang perlu anda berikan
informasi, yang lambat itu command insert/update/delete atau query?
Kalau query, single query atau bukan?
Salah satu jalan yang paling cepat yang bisa anda lakukan adalah dengan
menggunakan table partitioning, seperti yang sudah di posting di sini
oleh teman-teman, jadi anda bisa memaintain subset table lebih kecil.
Saya punya pengalaman table driver yang besarnya mencapai 1GB, ketika
query yang mengembalikan banyak baris data, misal saya melakukan select
count(*), sebelum di partisi total query hampir 10 detik, ketika saya
sudah partisi akhirnya kurang dari satu detik, saya belum test
performance DML-nya.
Sebenarnya untuk tuning ada methodologi yang bisa diikuti, secara
prinsip kalau melakukan tuning yang harus anda lihat seringkali adalah
bukan databasenya saja, namun, secara umum, urutan dan makin lama
kontribusi prosentase problemnya makin kecil:
1. Aplikasi, desain/arsitektur aplikasi termasuk design DB dan strategi
query ini punya kontribusi paling besar (saya agak lupa angka pastinya)
2. DB Engine + OS, kontribusi DB Engine ini lumayan
3. HW
Sebenarnya ada 5 yang harus diperhatikan, namun saya coba paparkan 3
saja yang paling sering dan gampang dilakukan. Kita perlu observasi
bagaimana prilaku aplikasi kita dulu, ada baiknya di challange dengan
point no-3, apakah penyebab buruknya performance karena adanya
bottleneck? Kalau ya, bottleneck dimana dan apa penyebab bottleneck?
Apakah bisa dikurangi faktor bottleneck atau dicari strategi komputasi
yang lain? Kalau tidak, apakah bisa ganti/upgrade hardware?
Kesemua urutan diatas itu sangat trivial, tergantung goal tuning anda,
budget, dan time frame. Goal dari tuning ini penting, karena tanpa ini,
maka anda akan tiada hari tanpa tuning :D
Thanks,
Regards,
Adhari C Mahendra
kenz
@ilham dan rizki : ya sepertinya perlu diperhitungkan pake innodb, meskipun transaksinya hanya single insert command, belum membutuhkan menggunakan transaksional. untuk mengubah ke innodb perlu persiapan penyesuaian aplikasi juga sepertinya.
@adhari : lambat secara keseluruhan terutama di query, dugaan sementara karena database terlalu besar per table, ada table yang mencapai 3GB lebih. table yang besar ini jika dicek selalu saja lambat untuk querynya.
baik saya akan pelajari table partitioning, semoga ini tidak terlalu susah untuk dipelajari untuk orang yg tidak mengenyam pendidikan IT :)
kemungkinan adanya botleneck juga ada, sedang saya selidiki. solusi yg tercepat memang sedang diusahakan penambahan hardware memorinya, atau mungkin langsung ganti server dan OSnya. OS yang sekarang Redhat yang sudah agak ketinggalan, mungkin menggunakan ubuntu atau ada saran teman-teman ttg OS ini?
Terima kasih,
Kenz
rizki nanda agam
https://calomel.org/network_performance.html
dan untuk tuning itu juga tidak bisa cepat kita harus testing dan menganalisa hasilnya lalu testing lagi sampai sesuai dengan keinginan kita :) jadi memantau dan menganalisa :D dan jangan segan2 untuk share disini :)
--
http://debian-id.org
crazy...@debian-id.org
Adhari C Mahendra
> Terima kasih tanggapannya teman-teman, lumayan mendapat pencerahan :)
>
> @ilham dan rizki : ya sepertinya perlu diperhitungkan pake innodb,
> meskipun transaksinya hanya single insert command, belum membutuhkan
> menggunakan transaksional. untuk mengubah ke innodb perlu persiapan
> penyesuaian aplikasi juga sepertinya.
>
yang perlu diperhatikan, kalau kondisi aplikasi tidak menggunakna
transaction context, maka mau pakai storage engine apapun tidak ada
bedanya, namun kalau dari aplikasi sudah di code dengan transaction
context, maka itu akan berbeda antara penggunaan storage engine yang
support transactional atau tidak.
> @adhari : lambat secara keseluruhan terutama di query, dugaan
> sementara karena database terlalu besar per table, ada table yang
> mencapai 3GB lebih. table yang besar ini jika dicek selalu saja lambat
> untuk querynya.
>
scan? atau single record? bagaimana dengan penggunaan index kalau? coba
cek query anda dengan query plan, apakah strategi query sudah sama
dengan ekspektasi (misal sudah benar-benar memanfaatkan index yang
dibuat atau tidak.
> baik saya akan pelajari table partitioning, semoga ini tidak terlalu
> susah untuk dipelajari untuk orang yg tidak mengenyam pendidikan IT :)
>
> kemungkinan adanya botleneck juga ada, sedang saya selidiki. solusi yg
> tercepat memang sedang diusahakan penambahan hardware memorinya, atau
> mungkin langsung ganti server dan OSnya. OS yang sekarang Redhat yang
> sudah agak ketinggalan, mungkin menggunakan ubuntu atau ada saran
> teman-teman ttg OS ini?
selain table terpartisi, index-pun juga di partisi, jadi anda juga harus
check apakah type dan column partisisi itu align dengan column yang di
index, kalau tidak, maka hitung-hitungan saya akan ada drawback,
khususnya ketika DML yang menyangkut perubahan/penambahan/penghapusan
column yang terindex atau jadi key partisi.
kenz
Mungkin hasil tuning-primer disini bisa menjelaskan lagi lebih lanjut, kira-kira bagian mana yang belum optimal. Xeon 4 Core dengan memori 6GB.
Uptime = 1 days 2 hrs 10 min 47 sec
Avg. qps = 107
Total Questions = 10175387
Threads Connected = 100
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 5 sec.
You have 98 out of 10175478 that take longer than 5 sec. to complete
Your long_query_time seems to be fine
BINARY UPDATE LOG
The binary update log is enabled
WORKER THREADS
Current thread_cache_size = 16
Current threads_cached = 0
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine
MAX CONNECTIONS
Current max_connections = 300
Current threads_connected = 101
Historic max_used_connections = 164
The number of used connections is 54% of the configured maximum.
Your max_connections variable seems to be fine.
MEMORY USAGE
Max Memory Ever Allocated : 3 G
Configured Max Per-thread Buffers : 4 G
Configured Max Global Buffers : 1 G
Configured Max Memory Limit : 5 G
Physical Memory : 5.93 G
Max memory limit seem to be within acceptable norms
KEY BUFFER
Current MyISAM index space = 8 G
Current key_buffer_size = 1 G
Key cache miss rate is 1 : 99
Key buffer fill ratio = 99.00 %
You could increase key_buffer_size
It is safe to raise this up to 1/4 of total system memory;
assuming this is a dedicated database server.
QUERY CACHE
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 15 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 48.13 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size
SORT OPERATIONS
Current sort_buffer_size = 4 M
Current read_rnd_buffer_size = 5 M
Sort buffer seems to be fine
JOINS
Current join_buffer_size = 132.00 K
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly
OPEN FILES LIMIT
Current open_files_limit = 1510 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine
TABLE CACHE
Current table_cache value = 512 tables
You have a total of 70 tables
You have 147 open tables.
The table_cache value seems to be fine
TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 78734 temp tables, 0% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine
TABLE SCANS
Current read_buffer_size = 3 M
Current table scan ratio = 970 : 1
read_buffer_size seems to be fine
TABLE LOCKING
Current Lock Wait ratio = 1 : 16
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
terima kasih,
kenz
Fajar A. Nugraha
> Barusan server mysql keok... hiks, cuma buat menghapus file data 1GB,
> loadnya bisa 200%, ckckckckckck... saya masih belum bisa berpikir jernih,
> apa yg salah.
Nggak ada yang salah kok Mas. Emang gitu. DB apapun (termasuk oracle)
akan bekerja SAAAANGAT berat jika mengahapus data dengan sql statement
DELETE FROM ... WHERE ...
>
> Mungkin hasil tuning-primer disini bisa menjelaskan lagi lebih lanjut,
> kira-kira bagian mana yang belum optimal. Xeon 4 Core dengan memori 6GB.
>
Saya tulis di sini beberapa tambahan yang blom disampaikan rekan lain :
(1) Partitioning, or no partitioning
Partitioning SANGAT membantu jika kita menghapus data secara berkala.
Untuk contoh yang Anda sampaikan di atas, partitioning akan sangat
membantu. Namun hati2 implementasinya, karna penerapan yang tidak
tepat (misal: buat 1000 partisi) malah membuat performansi jadi jauh
lebih buruk.
(2) Index
Index akan sangat mempercepat select, tetapi membuat insert/update
JAUH lebih lambat. Anda mesti tau dulu mana yang lebih penting untuk
Anda, performansi select ato insert. Dari situ bisa ditentukan index
sepeti apa yang paling tepat. Contoh nih, di tempat saya ternyata
bottleneck terjadi pada saat insert/update, jadi salah satu tuning
yang kami lakukan justru MENGURANGI jumlah index.
(3) Memori
Tergantung kebutuhan sih. Gambaran aja nih, di tempatku db MySQL yang
nanganin data "critical" itu dikasih HW 4 x Xeon E7330 (total jadi 16
core), 32 GB memory, di atas RHEL5 x86_64 (kalo masih pake i686 mah
percuma). Tapi nambah HW aja blom cukup lho. Karakteristik penggunaan
memori MyISAM dengan Innodb itu beda. Versi pendeknya sih kalo mau
memori bermanfaat maksimal, pake Innodb, dan set
innodb_buffer_pool_size=16384M
(4) storage engine
storage engine bisa sangat berpengaruh lho, regardless butuh tarnsaksi
ato nggak. Contohnya kalo pake myisam :
- setiap insert akan full table lock
- select dan select lain bisa barengan, tapi setiap select akan ngeblock insert
- kalo servernya tewas gak normal perlu myisamchk (bisa ditest
otomatis sih) yang bakal butuh waktu luaaaaaaama kalo tabelnya gede
In general kalo datanya gede sih mendingan pake innodb. Tapi
sebenernya innodb pun kurang optimal di beberapa area, sehingga
beberapa pihak (Percona misalnya) menawarkan versi khusus Innodb yang
udah ditambahin enhancement sehingga bisa lebih baik.
Tapi jangan terburu2 juga pingin pindah ke innodb. Mesti diplanning
dengan baik. Kalo datanya gede, convert table type itu bisa makan
sehari semalam ato bahkan lebih lho. Ada sih caranya biar bisa tetep
live selama convert, tapi itu cukup panjaaaaaang :D
(5) expert
Kalo emang dipake buat jualan, mending cari support yang bagus deh.
Soalnya emang gak ada cara "tinggal ubah ini, sekali klik langsung
beres". Seriously. Di versi komersial emang ada Mysql enterprise
monitor dan advisor yang bisa memonitor kondisi db dan ngasih saran
apa yang mesti diperbaiki. Tapi untuk implement perbaikannya itu tetep
perlu expert juga. DB lain (Oracle, MSSQL, SYbase, etc.) pun sama kok,
tetep perlu expert buat ngasih support yang bagus.
Kalo dananya cukup, silakan hubungi Sun, mungkin bila beli support
tambahan sehingga mereka bisa datengin expert dari Jepang (misalnya).
Tapi pasti mahal :D
Yang lebih murah, cari expert local yang emang udah berpengalaman
menangani sistem production yang skalanya sama atau lebih besar dari
sistemmu sekarang. Sebenernya di Indonesia juga udah ada Certified
MySQL DBA lho.
--
FAN
Fajar A. Nugraha
> untuk mengubah ke innodb perlu persiapan penyesuaian aplikasi
> juga sepertinya.
Not really. Tergantung penggunaannya, perubahan di sisi db (termasuk
storage engine) bisa transparan dari sisi aplikasi.
--
FAN
Adhari C Mahendra
> Saya tulis di sini beberapa tambahan yang blom disampaikan rekan lain :
> (1) Partitioning, or no partitioning
> Partitioning SANGAT membantu jika kita menghapus data secara berkala.
> Untuk contoh yang Anda sampaikan di atas, partitioning akan sangat
> membantu. Namun hati2 implementasinya, karna penerapan yang tidak
> tepat (misal: buat 1000 partisi) malah membuat performansi jadi jauh
> lebih buruk.
>
hapus, proses inilah yang makan waktu sangat panjang, sedangkan alter
drop partition itu hampir setara truncate, yang hanya drop definition
lalu hapus physical file. 1000 partisi secara teknis sebenarnya tidak
masalah asal resource anda cukup, kalau di Oracle idealnya ketika
membuat partisi di DB yang high load, 1 partisi di handle 1 thread CPU
(jadi tergantung tipikal CPU anda, ada CPU yang bisa 1 CPU 1 thread, ada
yang 2 thread, ada juga yang 64 thread, tergantung kocek :D), lalu satu
channel controller I/O, lalu refer ke satuan set spindle (yang ini
umumnya RAID 1+0 atau sejenis). Nah, di MySQL sendiri, sampai sekarang
belum terlalu support SMPU, karena typical programmingnya masih
multi-threading, tidak seperti Oracle yang selain multi-threading, dia
juga multi-process. Nah, pemilihan OS bisa jadi sangat berpengaruh untuk
leverage thread ke resource CPU yang ada.
Penggunaan Solaris 10 dengan ZFS sepertinya bisa membantu anda, karena
prinsipnya ZFS itu COW, jadi bisa lebih cepat dibandingkan dengan FS
yang konvensional, saya sudah test sendiri, perform better, namun belum
memenuhi goal tuning saya, akhirnya ketika 5.1 yang saya tunggu2 keluar,
akhirnya upgrade dan beresin pakai partitioning, kelar :D
> (2) Index
> Index akan sangat mempercepat select, tetapi membuat insert/update
> JAUH lebih lambat. Anda mesti tau dulu mana yang lebih penting untuk
> Anda, performansi select ato insert. Dari situ bisa ditentukan index
> sepeti apa yang paling tepat. Contoh nih, di tempat saya ternyata
> bottleneck terjadi pada saat insert/update, jadi salah satu tuning
> yang kami lakukan justru MENGURANGI jumlah index.
>
> (3) Memori
> Tergantung kebutuhan sih. Gambaran aja nih, di tempatku db MySQL yang
> nanganin data "critical" itu dikasih HW 4 x Xeon E7330 (total jadi 16
> core), 32 GB memory, di atas RHEL5 x86_64 (kalo masih pake i686 mah
> percuma). Tapi nambah HW aja blom cukup lho. Karakteristik penggunaan
> memori MyISAM dengan Innodb itu beda. Versi pendeknya sih kalo mau
> memori bermanfaat maksimal, pake Innodb, dan set
> innodb_buffer_pool_size=16384M
>
Secara umum, betul memang ada bottleneck kalau anda melakukan DML ke
MyISAM storage engine di saat yang sama ada yang melakukan select, maka
akan lock table, tapi ingat, hal ini terjadi jika dan hanya jika ketika
melakukan update data di middle of data files (free blocks). Artinya,
ketika ada process insert namun tidak append -insert yang mengisi data
kosong (free blocks) akibat proses delete- maka mekanisme locking
terjadi, locking juga pasti terjadi jika anda issue delete dan update,
namun tidak jika typical insert-nya adalah append. Oleh karena itu
kenapa kemarin saya bilang, design aplikasi itu jadi sangat penting...
> (4) storage engine
> storage engine bisa sangat berpengaruh lho, regardless butuh tarnsaksi
> ato nggak. Contohnya kalo pake myisam :
> - setiap insert akan full table lock
> - select dan select lain bisa barengan, tapi setiap select akan ngeblock insert
>
Insert yang append tidak akan berlaku axioma di atas...
Lebih baik pelajari ini
http://dev.mysql.com/doc/refman/5.1/en/table-locking.html sebelum anda
memutuskan mau stick on the MyISAM atau switch ke yang lain.
> - kalo servernya tewas gak normal perlu myisamchk (bisa ditest
> otomatis sih) yang bakal butuh waktu luaaaaaaama kalo tabelnya gede
> In general kalo datanya gede sih mendingan pake innodb. Tapi
> sebenernya innodb pun kurang optimal di beberapa area, sehingga
> beberapa pihak (Percona misalnya) menawarkan versi khusus Innodb yang
> udah ditambahin enhancement sehingga bisa lebih baik.
> Tapi jangan terburu2 juga pingin pindah ke innodb. Mesti diplanning
> dengan baik. Kalo datanya gede, convert table type itu bisa makan
> sehari semalam ato bahkan lebih lho. Ada sih caranya biar bisa tetep
> live selama convert, tapi itu cukup panjaaaaaang :D
>
Kalau itu masalah catalog problem, karena tidak transactional maka
consistency ini memang issue di MyISAM.
Mungkin sedikit trick dari saya, yang saya lakukan selama ini saya
menggunakan replication, master anda bisa menggunakan InnoDB jadi
benefit InnoDB anda bisa rasakan, jadi semua DML operation pasti
perginya ke master, dan slave saya gunakan MyISAM, hal ini bisa anda
lakukan selama aplikasi anda deal dengan delay updated data yang
bermigrasi dari master ke slave, ibaratnya data telat 0-3 menit masih
ok, maka anda bisa ambil benefit seperti ini, dan juga aplikasi anda kan
top up pulsa, yang umumnya adalah menggunakan SMS dan SMS itu asynch,
jadi telat-telat dikit masih acceptable :D kecuali anda design synch,
baru cerita lain karena bisa habis resource anda kalau anda
memperpanjang timeout...
Kalau mau lebih cepat lagi, anda bisa pakai blackhole untuk masternya,
kebetulan saya gunakan ini untuk menghemat space, karena master pasti
tidak pernah saya query. Keuntungan model ini, salah satunya adalah anda
perlu baca lebih jauh tentang perbandingan writing single page/row
dengan yang bulk di sisi I/O.
> (5) expert
> Kalo emang dipake buat jualan, mending cari support yang bagus deh.
> Soalnya emang gak ada cara "tinggal ubah ini, sekali klik langsung
> beres". Seriously. Di versi komersial emang ada Mysql enterprise
> monitor dan advisor yang bisa memonitor kondisi db dan ngasih saran
> apa yang mesti diperbaiki. Tapi untuk implement perbaikannya itu tetep
> perlu expert juga. DB lain (Oracle, MSSQL, SYbase, etc.) pun sama kok,
> tetep perlu expert buat ngasih support yang bagus.
> Kalo dananya cukup, silakan hubungi Sun, mungkin bila beli support
> tambahan sehingga mereka bisa datengin expert dari Jepang (misalnya).
> Tapi pasti mahal :D
> Yang lebih murah, cari expert local yang emang udah berpengalaman
> menangani sistem production yang skalanya sama atau lebih besar dari
> sistemmu sekarang. Sebenernya di Indonesia juga udah ada Certified
> MySQL DBA lho.
>
>
Sepertinya penulis ini Certified MySQL DBA? Berarti ada local expert
yang bisa di hire :D
abangkis
desain untuk lebih mendukung Scale Out secara Horizontal daripada
Vertikal. Dengan kata lain memperbanyak instance server di mesin yang
berbeda akan menuai hasil yang lebih bagus daripada melakukan upgrade
mesin dengan spesifikasi yang lebih tinggi. Tapi seperti yang adhari
bilang Tuning itu amat bergantung dengan banyak hal, tidak ada yang
generik. Tetapi karena design MySQL yang seperti itu, mungkin lebih
layak dicoba terlebih dahulu untuk melakukan Scaling Secara Horizontal
daripada melakukan MicroTuning.
2009/2/6 Adhari C Mahendra <adhari....@sun.co.id>:
Fajar A. Nugraha
> resource anda cukup,
Untuk MySQL nggak gitu deh. Masih ada bugnya yang menyebabkan
paritioning banyak jadi luambat. Kalo cuma dikit sih OK2 aja.
Pernah nyoba? Yang saya coba sih dengan partition sekitar 100 aja udah
keliatan banget drop performancenya (dan resource masih sangat cukup
lho)
Monty aja bilang "Partitioning is very slow and can become unusable if
you have a large number of partitions. This happens even if you only
use a few of the underlying tables in your query."
http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html
Pernah juga baca bug reportnya sih, cuma blom ketemu lagi linknya.
> Penggunaan Solaris 10 dengan ZFS sepertinya bisa membantu anda, karena
> prinsipnya ZFS itu COW
zfs lebih membantu, iya, tapi untuk case ini nggak ngaruh banyak kok.
MyISAM memanfaatkan cache OS (di mana cache zfs dan ext3 nggak jauh
beda kok performansinya), sementara untuk innodb cachenya dimanage
MySQL langsung (gak pake cache OS).
Tambahgan, sharing aja, di tempatku pernah mebandingkan performansi
MySQL di atas Linux dengan ext3 (di server x86 paling bagus yang kita
punya), opensolaris dengan zfs (di server x86 yang sejenis), dan
solaris dengan zfs (di atas server sparc paling bagus yang kita
punya). Untuk test case itu ternyata server x86 lebih cepet dibanding
sparc, dan linux/ext3 dengan opensolaris/zfs hampir setara.
Tapi sekali lagi, itu test case di tempatku lho. Beda load mungkin
beda hasilnya. Kalo gak salah Sun pernah ngeluarin hasil benchmark
dimana solaris/ufs lebih cepet dibanding linux/ext3 untuk MySQL di
atas server x86-nya Sun.
Saat itu sebenernya sempat mikir untuk mengganti Linux dengan
opensolaris karna zfs punya fitur snapshot yang akan sangat membantu
proses backup (I tried lvm snapshot on LInux as well, but got
performance problems). Cuma masalahnya aplikasi lain yang digunakan
blom ada binarynya untuk solaris x86. Compile sendiri bisa sih, tapi
ribet kalo mau dideploy di sekian puluh server. Jadi akhirnya, untuk
beberapa server pilihan, kita tetep pake linux, tapi untuk
filesystemnya pake zfs-fuse.
> Insert yang append tidak akan berlaku axioma di atas...
> Lebih baik pelajari ini
> http://dev.mysql.com/doc/refman/5.1/en/table-locking.html sebelum anda
> memutuskan mau stick on the MyISAM atau switch ke yang lain.
Tapi kalo ngeliat datanya dihapus secara berkala, maka kemungkinan ada
hole di tengah file MyISAM bakal lebih gede :D
--
FAN
abangkis
>
>
> Tapi kalo ngeliat datanya dihapus secara berkala, maka kemungkinan ada
> hole di tengah file MyISAM bakal lebih gede :D
>
> --
> FAN
>
yup betul sekali, karena natur dari Engine MyISAM sendiri amat
memungkinkan untuk terjadi fragmentasi. Untuk melakukan defragmentasi
bisa menggunakan mysqloptimize. Tetapi seperti saya bilang sebelumnya,
micro tuning seperti ini sepertinya sudah tidak mencukupi. Lebih baik
effortnya dipergunakan untuk menyesuaikan arstitektur dengan kebutuhan
saat ini.
Cheers
Abangkis
Adhari C Mahendra
> Untuk MySQL nggak gitu deh. Masih ada bugnya yang menyebabkan
> paritioning banyak jadi luambat. Kalo cuma dikit sih OK2 aja.
>
> Pernah nyoba? Yang saya coba sih dengan partition sekitar 100 aja udah
> keliatan banget drop performancenya (dan resource masih sangat cukup
> lho)
>
>
agak sedikit melambat, cuma tidak bisa dibilang jatuh.
> Monty aja bilang "Partitioning is very slow and can become unusable if
> you have a large number of partitions. This happens even if you only
> use a few of the underlying tables in your query."
>
> http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html
>
> Pernah juga baca bug reportnya sih, cuma blom ketemu lagi linknya.
>
>
>
>> Penggunaan Solaris 10 dengan ZFS sepertinya bisa membantu anda, karena
>> prinsipnya ZFS itu COW
>>
>
> zfs lebih membantu, iya, tapi untuk case ini nggak ngaruh banyak kok.
> MyISAM memanfaatkan cache OS (di mana cache zfs dan ext3 nggak jauh
> beda kok performansinya), sementara untuk innodb cachenya dimanage
> MySQL langsung (gak pake cache OS).
>
> Tambahgan, sharing aja, di tempatku pernah mebandingkan performansi
> MySQL di atas Linux dengan ext3 (di server x86 paling bagus yang kita
> punya), opensolaris dengan zfs (di server x86 yang sejenis), dan
> solaris dengan zfs (di atas server sparc paling bagus yang kita
> punya). Untuk test case itu ternyata server x86 lebih cepet dibanding
> sparc, dan linux/ext3 dengan opensolaris/zfs hampir setara.
>
> Tapi sekali lagi, itu test case di tempatku lho. Beda load mungkin
> beda hasilnya. Kalo gak salah Sun pernah ngeluarin hasil benchmark
> dimana solaris/ufs lebih cepet dibanding linux/ext3 untuk MySQL di
> atas server x86-nya Sun.
>
throughput, bisa jadi beda.
> Saat itu sebenernya sempat mikir untuk mengganti Linux dengan
> opensolaris karna zfs punya fitur snapshot yang akan sangat membantu
> proses backup (I tried lvm snapshot on LInux as well, but got
> performance problems). Cuma masalahnya aplikasi lain yang digunakan
> blom ada binarynya untuk solaris x86. Compile sendiri bisa sih, tapi
> ribet kalo mau dideploy di sekian puluh server. Jadi akhirnya, untuk
> beberapa server pilihan, kita tetep pake linux, tapi untuk
> filesystemnya pake zfs-fuse.
>
>
>> Insert yang append tidak akan berlaku axioma di atas...
>> Lebih baik pelajari ini
>> http://dev.mysql.com/doc/refman/5.1/en/table-locking.html sebelum anda
>> memutuskan mau stick on the MyISAM atau switch ke yang lain.
>>
>
> Tapi kalo ngeliat datanya dihapus secara berkala, maka kemungkinan ada
> hole di tengah file MyISAM bakal lebih gede :D
>
>
kenz
akhirnya, sedikit membaik ..... setelah yg expert turun tangan.. hehe, setelah saya nyerah juga...
ini tuning yg sedikit lebih baik dari sebelumnya, cpu lebih stabil, sepertinya karena saya salah memperbesar key buffernya, setelah diturunkan hasilnya cukup memuaskan. ya mesti coba-coba untuk tuning, dan mengikuti tutorial di internet tidak menjamin itu baik untuk sistem kita.
berikut setting my.cnf yg dirubah :
key_buffer = 512M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 6M
myisam_sort_buffer_size = 64M
thread_cache_size = 32
query_cache_size = 160M
log_slow_queries = /var/lib/mysql/mysqld_slow.log
long_query_time = 3
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
sekedar sharing aja, kalo ditanya gimana logikanya, saya gak bisa njelasin, masih mempelajari :)
thanks,
kenz