Исправление AndreyKl, (текущая версия) :
да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.
Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.
В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.
Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.
А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра кажется (хотя заметная вполне).
на правах «получуши для идей (ака брейншторминг)»: скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?
диск файл обьемом 4 гб, то первая половина заливается на скорости 500-700мбайт\сек а дальше падает до 100-150мбайт\сек
это он сначала кеширует в память, а потом начинает ждать записи на диск (видно кеш гдето 2гб по дефолту).
Исправление AndreyKl, :
да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.
Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.
В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.
Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.
А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра кажется (хотя заметная вполне).
на правах «получуши для идей (ака брейншторминг)»: скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?
Исправление AndreyKl, :
да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.
Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.
В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.
Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.
А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра кажется (хотя заметная вполне).
скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?
Исходная версия AndreyKl, :
да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.
Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.
В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.
Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.
А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра.
скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?