URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 45196
[ Назад ]

Исходное сообщение
"Увеличение производительности СУБД, через использование RAM-диска"

Отправлено opennews , 17-Ноя-08 21:56 
"Как использовать ram-диск для увеличения производительности дисков? (http://www.unixpin.com/wordpress/2008/11/16/vxvm-ram-disk/)" - увеличение производительности СУБД, через использование RAM-диска. Суть идеи в создании программного RAID, один из разделов в котором RAM-диск, а второй - физический диск. При записи данные будут записываться на оба устройства, а при чтении из RAM-диска.

URL: http://www.unixpin.com/wordpress/2008/11/16/vxvm-ram-disk/
Новость: http://www.opennet.me/opennews/art.shtml?num=18950


Содержание

Сообщения в этом обсуждении
"Увеличение производительности СУБД, через использование RAM-диска"
Отправлено netc , 17-Ноя-08 21:56 
интересная идея совсем кстати ;) а то банк клиент с сжатой акцессовской базой просто реальный тормоз

а на оракл дорого переходить, п.с на другом не работает ;)

да и кстати кто как думает надежность то по идее не страдает ?


"Увеличение производительности СУБД, через использование RAM-..."
Отправлено Щекн Итрч , 17-Ноя-08 22:44 
полная И Р НЯ :)
имея 4 GB ОЗУ решил заставить Мускула использовать под временные JOIN таблицы RAM диск.
накладные расходы при работе с RAM диском на порядок выше, чем с буферами ОСи.
а имея ввиду брендовый SCSI RAID адаптер с 256 метров BBWC - эти рыдания яичные ваще тормозят раз в 100...

"Увеличение производительности СУБД, через использование RAM-диска"
Отправлено netc , 17-Ноя-08 22:03 
Ув. автор!

Рад попробывать, только вот проблема у меня немножко не unixway

т.к. похожую задачу нужно решить локально на компьютере глав буха

да задачка проще, думаеться

но все таки буду рад попробывать что-то может быть в локальной vm в которой так сказать поднять линукс, самбу в ней также настроить рам-диск т.е. все разрулить внутри vm а наружу к винде показать только samb'u к ресурсу которой и будет обрашаться клиент банк

но увы предсказать как это будет работать лучше или хуже я не могу

вообще интересно кто что думает по этому поводу ?

ИМХО типичная задача сис.админа ;) буду пробывать по возможности


"Увеличение производительности СУБД, через использование RAM-..."
Отправлено netc , 17-Ноя-08 22:03 
>Ув. автор!

p.s. надеюсь он меня слышит


"Увеличение производительности СУБД, через использование RAM-..."
Отправлено Аноним , 17-Ноя-08 23:14 
Существуют рамдиски под виндовс. Может как нить через него?

"Увеличение производительности СУБД, через использование RAM-диска"
Отправлено User294 , 17-Ноя-08 22:40 
Мсье знают толк в извращениях.А ... эээ ... пардон, а просто отдать столько же оперативки на кэш - не спортивно чтоли?Или это чем-то хуже?Ну а всякие memcached и вовсе считерят не только достав из оперативки результат но и вообще не гоняя монструозный движок БД лишний раз.Какой плюс у данного подхода?

"Увеличение производительности СУБД, через использование RAM-..."
Отправлено User294 , 17-Ноя-08 22:42 
А, понял, это такой эстетичный способ надувалова жадного оракла - заворкэраундили его ограничения типа.

"Увеличение производительности СУБД, через использование RAM-диска"
Отправлено Аноним , 18-Ноя-08 01:24 
В чем принципиальное отличие между данным половым извращением и обычным кэшем?

"Увеличение производительности СУБД, через использование RAM-диска"
Отправлено Аноним , 18-Ноя-08 03:17 
имхо велосипед - нормальная база и так должна все эффективно кешировать

"Увеличение производительности СУБД, через использование RAM-..."
Отправлено Аноним , 18-Ноя-08 03:19 
>имхо велосипед - нормальная база и так должна все эффективно кешировать

и память лучше отдать ей явно для кеша, чем тратить ее на то на что она может и не понадобиться


"Увеличение производительности СУБД, через использование RAM-..."
Отправлено User294 , 18-Ноя-08 15:50 
>имхо велосипед - нормальная база и так должна все эффективно кешировать

Удел любителей проприетарщины - трах с вот такими вот левыми воркэраундами.Я так понимаю что все это сделано для того чтобы заворкэраундить (удалив гланды через ж**у автогеном) ограничения оракля а вовсе не потому что это решение чем-то лучше других =\.Готов поспорить что оракловцы развешивая ограничения не рассчитывали на тех кто удаляет гланды через ж-у автогеном :)


"Увеличение производительности СУБД, через использование RAM-диска"
Отправлено netc , 18-Ноя-08 09:16 
Большинсво за то, что это извращение, ну что-ж буду пытаться найти другой более интересный способ, только вот ни как в голову не прийдет мысль что делать с аксессом ;(

"Увеличение производительности СУБД, через использование RAM-"
Отправлено Leo , 18-Ноя-08 09:50 
Что такое "сжатая акцесовская база" ?
Если клиент написан "грамотно" - не поможет ничего.
Тормозит по чему (именно по _пробел_ чему) ?
По процу, по диску, по сетке, по раму?

Данных много в базе? Сиквел поставьте. Последний в бесплатной редакции, кажется, не ограничивает объём данных, только - использование 1 ядра и 1Г РАМ.


"Увеличение производительности СУБД, через использование RAM-"
Отправлено Leo , 18-Ноя-08 10:41 
>Данных много в базе? Сиквел поставьте. Последний в бесплатной редакции, кажется, не
>ограничивает объём данных, только - использование 1 ядра и 1Г РАМ.

Прошу прощения, наврал 2 раза.
Главное - база до 4Г (но это не мало, уверяю; если бухгалтерия ворочает бОльшими объёмами, ей не грех и воркгруп, хотя бы, купить)
Ну, а на сладкое - не 1 ядро, а 1 физический процессор. Т.е. в десктоп-реалиях - до 4-х ядер. Что даже больше, чем надо для памяти 1Г :)


"Увеличение производительности СУБД, через использование RAM-диска"
Отправлено Аноним , 19-Ноя-08 02:28 
Я одного не понял, почему автор не смог ораклу выделть более 2G. Нет там никаких ограничений вроде. http://download.oracle.com/docs/cd/B19306_01/license.102/b14...