История изменений

да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.

Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.

В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.

Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.

А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра кажется (хотя заметная вполне).

на правах «получуши для идей (ака брейншторминг)»: скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?

диск файл обьемом 4 гб, то первая половина заливается на скорости 500-700мбайт\сек а дальше падает до 100-150мбайт\сек

это он сначала кеширует в память, а потом начинает ждать записи на диск (видно кеш гдето 2гб по дефолту).

да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.

Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.

В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.

Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.

А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра кажется (хотя заметная вполне).

на правах «получуши для идей (ака брейншторминг)»: скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?

да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.

Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.

В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.

Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.

А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра кажется (хотя заметная вполне).

скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?

да, по рам-диску, поглядите системными инструментами загрузку дисков (io waits или как оно), если оно большое рам-диск может помочь с высокой вероятностью.

Да, кстати, тут я протупил, выше человек объяснил: если 24 гб рамы, а база 600мб, то всё уже должно лежать в памяти.

В простое и при запуске скрипта, у вас упирается в CPU, очевидно. Выход - только глядеть запросы. Т.е. надо ловить то что жрёт процессор как не в себя. И глядеть глазами на explain запроса. Вполне возможно что банальные индексы (там где нужно) сотворят чудо расчудесное.

Впринципе, немного странно что 99% cpu используется в простое, так на первый взгляд. Это похоже на базы работу в один поток, что может давать подсказку о локах в запросах. Но это так же может быть резульаттом того что клиент подцеплен всего один и делает запросы строго последовательно.

А вот почему бекап так долго разворачивается, я объяснить затрудняюсь. Соседняя база может мешать разворачиванию бекапа только если она ресурсы съела (процессор, дисковое ио, память), но в у вас такого не наблюдается: все ресурсы есть. 12% iowait в топе не похоже на проблему. тотал диск райт 10.91Мб тоже не слишком большая цифра.

скажите, а на этой отдельной базе индексы стоят? как оно по 50к «последних» записей делает селект?