Skocz do zawartości

PHP / pamięciowa baza danych z Row Level Locking


slawek22

Rekomendowane odpowiedzi

Praktycznie taka sama wydajność tylko teoretycznie lepsze bezpieczeństwo danych:

W przypadku bazy Innodb oraz dysku RAM

* baza jest usuwana po restarcie severa

* obsługa row level locking

* Szybkość odczyty oraz zapisu CrystalDismark { bez ECC }

Odczyt: 861Mb/s 100mb plik

Zapis: 847Mb/s

Mysql memory

* baza jest usuwana po restarcie MySql

* Wydajność zapewne taka sama

Dyski SSD

W przypadku tych dysków polecam te które mają wbudowaną pamięć np 64Mb, u mnie na ExFAT oraz odpowiednie alokowaniu dysku osiągam ponad 200Mb/s

Odnośnik do komentarza
Udostępnij na innych stronach

Głównie zależy mi na wydajności insert. Mała tabela pamięciowa ok. 100k rekordów, b-tree, do 500q/sec 80% zapis, 20% odczyt, parę delete, wszystko po pri_key.

Ewidentnie jakaś niedróbka w kodzie mySQL - co 20-30 sekund WRITE LOCK na tabelę i wątki czekają po 2-3s, chociaż wykorzystanie CPU ok 5-10%.

Partycjonowanie na 10k x 10 tabel nie pomaga, wyłączenie cache też nie, innoDB zarzyna dysk. Pomysł?

BTW: da się ustawić mysql tak, żeby tylko jedna baza innoDB była w pliku/RAM a reszta w tablespace?

Memory: baza jest usuwana po restarcie MySql - czyszczone są tylko dane, czy tabela innoDB po restarcie zniknie jeśli była umieszczona w pamięci RAM?

Odnośnik do komentarza
Udostępnij na innych stronach

Głównie zależy mi na wydajności insert. Mała tabela pamięciowa ok. 100k rekordów, b-tree, do 500q/sec 80% zapis, 20% odczyt, parę delete, wszystko po pri_key.

Jest w mysql opcja iż mysqld_low-priority-updates. Trza kombinować np SQL_NO_CACHE, UPDATE LOW_PRIORITY, SELECTs HIGH_PRIORITY dodanie większe ilości ramu czy memcache w ostateczności.

BTW: da się ustawić mysql tak, żeby tylko jedna baza innoDB była w pliku/RAM a reszta w tablespace?

innodb_file_per_table - ale trzeba ponownie utworzyć tabele oraz dodanie osobnej ścieżki polecam połączenie się przez MySQL Administrator i dokonanie stosownych zmian każda tabela Innodb może mieć osobną lokalizacje

Jeżeli dodajesz za każdym razem dużo rekordów użyj transakcji ale to chyba wiadomo :)

https://dev.mysql.com/doc/refman/5.0/en/inn...tion-model.html

https://ez.no/developer/articles/tuning_mys...ite_performance

b-tree, do 500q/sec 80% zapis, 20% odczyt

W moim przypadku rozbiłem tabele użytkowników na mniejsze tabele i to dało dobry efekt.

Może czas pomyśleć nad replikacją na główmy serwerze będzie zapis a na slevie tylko odczyt. Widziałem w działaniu takie coś iż były uruchomione 2 bazy danych na jednej maszynie.

https://webreflection.blogspot.com/2009/06/...y-solution.html

https://www.mysqlperformanceblog.com/2006/0...and-for-update/

[Tutaj są jakieś niby rozwiązania]

Czyli zaloguj się do servera monitoruj zapytania sprawdź na jakim etapie jest locking np. Copy to tmp table, sprawdź indeksy EXAPLAIN

Odnośnik do komentarza
Udostępnij na innych stronach

Zarchiwizowany

Ten temat przebywa obecnie w archiwum. Dodawanie nowych odpowiedzi zostało zablokowane.

  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę. Warunki użytkowania Polityka prywatności