Процент временных таблиц потребовавших создание на диске
Процессор Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 3876.531 Mhz X 8
Оперативная память 3179284 / 32876156 kB
Размер дискового пространства 212975 Mb
Файл подкачки (swap) 12574716 kB
Средняя загрузка (1, 5, 15 мин) 1.06 0.57 0.40
Продолжительность работы 5 days 21 hours 25 minutes
Напрягают 2 параметра 1 работа почтового сервера - удалил стандартную, поставить postfix, стало 0.3 - все равно время медленее эталонного - но это фигня.
А вот параметры базы напрягают очень дико.
Вот настройки мускула
explicit_defaults_for_timestamp = 0
sql_mode=
transaction-isolation = READ-COMMITTED
innodb_flush_method = O_DIRECT
innodb_file_format = Barracuda
max_heap_table_size = 512M
tmp_table_size = 512M
innodb_buffer_pool_size=10G
innodb_additional_mem_pool_size=32M
innodb_file_io_threads=8
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_lock_wait_timeout=50
innodb_log_buffer_size=32M
innodb_flush_log_at_trx_commit=2
innodb_log_file_size=256M
innodb_file_per_table = 1
optimizer_search_depth = 0
join_buffer_size = 4M
key_buffer_size=16M
sort_buffer=8M
read_buffer_size=16M
query_cache_size=128M
query_cache_type=1
query_cache_limit = 64M
Кто что посоветует покрутить?
PS: Пожалуйста не нужно читать лекцию про то что это все попугаи, писькомерство и т.п. если мы об этом спрашиваю, значит мне нужны эти цифры(как минимум для клиентов).
Относительно базы данных рекомендую отказаться от innodb_file_per_table = 1 (чтобы все хранилось в одном файле ibdata), правда придется сдампить базы, затем отключить, переименовать /var/lib/mysql и переинцииализировать и снова залить mysql базы
Относительно почтовой системы разобраться что у вас настроено при отправке почты, возможно долго резолвится имя сервера если оправка по smtp, следовательно прописать записи в /etc/hosts к которым идет подключение или если медленный резровер настроить локальных bind и его прописать в /etc/resolv.conf
Относительно базы данных рекомендую отказаться от innodb_file_per_table = 1 (чтобы все хранилось в одном файле ibdata), правда придется сдампить базы, затем отключить, переименовать /var/lib/mysql и переинцииализировать и снова залить mysql базы
Относительно базы данных рекомендую отказаться от innodb_file_per_table = 1 (чтобы все хранилось в одном файле ibdata), правда придется сдампить базы, затем отключить, переименовать /var/lib/mysql и переинцииализировать и снова залить mysql базы
Относительно почтовой системы разобраться что у вас настроено при отправке почты, возможно долго резолвится имя сервера если оправка по smtp, следовательно прописать записи в /etc/hosts к которым идет подключение или если медленный резровер настроить локальных bind и его прописать в /etc/resolv.conf
А почему отказаться? Просто я наборот читал что функция очень полезна, на серваке около 15 сайтов, у половины из них база около гига - не будет ли обратного эффекта?
это если переконвертировать myisam в innodb, а если уже innodb каждая таблица в своем файле, то придется пересоздать, иначе-то как, я так делал.
Зато у innodb_file_per_table достоинства что при удалении баз данных (если на сервере не один-два сайта на битриксе) высвобождается место (а не многогигабатный ibdata файл который растет), да и повреждается в случае внезапных падений mysql/ребутах такая база значительно намного реже или пострадает одна табличка, а не перестает запускаться весь сервер
А почему отказаться? Просто я наборот читал что функция очень полезна, на серваке около 15 сайтов, у половины из них база около гига - не будет ли обратного эффекта?
/etc/my.cnf
НО я не рекомендую вот так тупо копипаст делать, нужно смотреть конкретные данные нагрузки, какие запросы, какие базы, наличие индексов и т.д.
mysql такая штука, что при неправильных лимитах - будет медленно всё
Те же индексы, если их 2 Мб, нет смысла выделять 10 Gb памяти, и так почти со всем параметрами
а если у меня ISPmanager, может через него можно?
Кеш запросов (размер) 0 Б Включите кеширование запросов (установить значение параметра query_cache_size больше или равным 8M, но не более 128M).
Кеш потоков 0 Кеш потоков (thread_cache_size) отключен. В качестве начального значение установите значения этого параметра равным 4.
Кеш открытых таблиц 0.05% Эффективность кеша открытых таблиц (Open_tables / Opened_tables). Если значение эффективности менее 20%, то требуется увеличить значение параметра table_open_cache (текущее значение: 64). Увеличивайте параметр постепенно чтобы избежать превышения лимитов на количество одновременно открытых файлов в операционной системе.
Вот красным битрикс выделяет, а вообще проблема, сервер стал отвечать вместо 1-2 секунд по 10. ну вроде как узкое место БД стало. по каким причинам не ясно. Пробую пока БД ускорить
Иногда при выполнении длительных или плохо написанных запросов в PostgreSQL происходят разные неприятные вещи типа внезапного сбоя процесса или краша всего сервера.
В таких случаях на носителе могут остаться "мертвые души" - файлы (иногда совсем немаленькие, а вполне сравнимые по объему со всей остальной базой), которые были созданы во время работы процесса в качестве временного хранилища промежуточных данных.
Эти данные уже никому не нужны, никем не могут быть использованы, но сервер все равно не торопится избавиться от них как Плюшкин.
Сегодня посмотрим, как их можно найти и безболезненно "зачистить".
Разыскиваем temp buffers
Первая категория возникающих проблем - временное использование дискового пространства при выполнении узла плана, если необходимый объем памяти не уместился в work_mem.
Получить такой эффект достаточно просто - забыть поставить или выбрать слишком большой предел рекурсии:
Корень беды заключается в том, что для сортировки рекурсивной выборки T необходимо вычислить и куда-то записать ее полностью, что и показывает атрибут temp written :
Давайте теперь сэмулируем неприятность, случившуюся во время выполнения запроса - увеличим для этого ограничение рекурсии на порядок:
Плохо "убитый" клиентский процесс тянет за собой postmaster и весь PostgreSQL-сервер
Сервер быстро упал - быстро поднялся. Но место на диске у нас убыло почти на 4GB - где же они?
Найти их нам поможет функция получения списка временных файлов pg_ls_tmpdir:
Данная функция появилась только в PostgreSQL 12, поэтому если версия вашего сервера младше, придется воспользоваться pg_ls_dir по /base/pgsql_tmp - это как раз то место, где сохраняются временные файлы, которые мы ищем.
Эти файлы в имени содержат PID процесса, который их породил. Поэтому, чтобы не зачистить лишнего, сразу проверим, что среди активных запросов такого идентификатора нет:
Теперь осталось пройти по полученному списку и поудалять. Замечу, что если "прибивать" запрос через pg_terminate_backend(pid) , то и сервер не "падает", и подобного "мусора" в каталоге не остается.
не выходит поменять query_cache_size делаю изменения, жму сохранить, он вроде сохранит и перезапустит, но значение остается нулевым(
query_cache_type значение 1 стоит если что. но читал что включает он автоматом при изменении значения размера
Ничейные TEMPORARY TABLE
Теперь в списке схем нашего соединения появилась pg_temp_5 :
Именно на эту схему проецируется обращение к псевдосхеме pg_temp - то есть в этом соединении запросы TABLE x , TABLE pg_temp.x и TABLE pg_temp_5.x будут эквивалентны, пока эта временная таблица существует.
Но раз эта таблица полноценная, а не "полуфабрикат", как в случае temp buffers , то мы должны бы увидеть ее и в pg_class :
Выяснение такой странной нумерации схем приводит к письму Tom Lane аж от февраля 2003:
> What is the origin of these schemas? local temporary tables? sorts?
Right, they're made to hold temporary tables. The first time a givenbackend does CREATE TEMP TABLE, it looks for a pg_temp_n schema, and makes it if it's not there. On shutdown, it removes the temp tables, but it seemed like a waste of cycles to remove the pg_temp_n schema itself.
(ObTrivialFact: the 'n' is the backend's pgproc slot number, so it's known not to be in use by any concurrently running backend. But it will certainly be used again in future.)
Итак, при штатном гашении сервера сами файлы временных таблиц должны быть вычищены. Собственно, а где они?
В отличие от temp buffers, относящихся ко всему серверу, файлы временных таблиц и индексов относятся к конкретной базе, но имеют несколько другой формат имени:
То есть имя файла временного объекта выглядит как t_ . Если сейчас мы "уроним" сервер снова, эти файлы останутся, как и записи в pg_class .
Чтобы избавиться от них, можно прогнать VACUUM FULL по всей базе, но это практически невозможно, если она достаточно велика. Или просто подождать когда то же самое доберется сделать autovacuum :
Но если таблиц в базе немало, это может наступить ой как нескоро, а дисковое пространство по-прежнему будет занято.
Поэтому, чтобы выловить заведомо "ничейные" временные таблицы, сравним время последней модификации их файлов со временем перезагрузки сервера, которое в обычных условиях можно определить как время сброса статистики по "нулевой" базе:
Мы тут с коллегами пили пиво с водкой были на симпозиуме, обсуждали проблемы оптимизации софта в глобальном масштабе. Пришли к промежуточному выводу, что простое упразднение практик построения архитектуры софта в микросервисной парадигме (привет докер!) позволит снизить мировую потребность в вычислительной мощности примерно в 1,7 раза. Если заняться оптимизацией и переписать самый жир на С, то можно ужаться ещё в 1,5-2 раза. Как то так.
Здравствуйте. Уже много лет играю в Minecraft и хотел бы узнать как оптимизировать его под линуксом. У меня рабочий пк очень старенький и очень слабый, по современным меркам,но т.к я играю только в майнкрафт, а все остальные задачи не требуют больших мощностей проблем не испытываю. Но все же, хотелось бы поиграть немного с большей прорисовкой чанков и с меньшим кол-вом подвисаний и резких просадок. Слышал что помогает замена обычного open-jdk на Liberica, но ни подтверждения этому, ни еще каких либо фактов я не увидел, да и при непосредственной установке ничего мне это не дало. Как основной дистрибутив у меня Arch Linux + XFCE4. На компьютере стоит Intel Pentium G630 2.70Ghz + 4GB RAM DDR3. Видеокарты нет, лишь встроенная. Если кто вообще еще в Minecraft играет, то посоветуйте что-нибудь, будет интересно послушать. Всем заранее спасибо за ответы.
Кто такие фичи оптимизации знает? Например вот numa=off. У меня не много процессорная сборка и этот планировщик там как пятая нога. Или mitigations=off, для домашнего компа норм. Какие ещё опции для упрощения жизни есть?
Привет. Друг задал мне вопрос - можно ли настроить конфигурацию ядра так, чтобы оптимизировать его под быстрые переключения тактовой частоты при повышениях нагрузки и стоит ли это делать в принципе?
Можно ли резко повысить тактовую частоту (меньше 10 мс / 50 мс или 1 секунды)? Сильно ли это вообще зависит от настроек ядра, или стоит смотреть в настройки BIOS в первую очередь?
Раньше, когда еще не было столько виртулизации в ПО, различного рода абстракций и наслоений в архитектуре, а программисты пытались как можно лучше адаптировать код к производительности, такой подход, как оптимизация CFLAGS флагов сборки под конкретный процессор оправдывал себя и задавало соотвествующий выхлоп. А сейчас?! Хороших программистов стало крайне мало, количество различного рода микроархитектур стремится к бесконечности, а на задействующие ресурсы, при использование ПО на стороне пользователя - плевать, как снежный ком нарастает зависимость пакетов при сборки и тд. Стоит ли вообще этим заниматься?!
Перемещено hobbit из general
На просторах интернетов полным полно всевозможных статей, постов и тем на форумах, где обсуждаются или «реквестируются» всякие «фишки» и советы по оптимизации «онтопика». Но многие из описываемых там вещей являются либо неактуальными, либо изначально не несут в себе никакой пользы, а иногда даже и вред. При этом сразу понять, является ли совет полезным или нет, зачастую не получается. Поэтму предлагаю в этой теме делиться примерами сабжа и объяснениями, почему они устарели/не работают/вредны.
Начну с того, что первым вспомнилось:
1. sudo make install .
Довольно часто в инструкциях по установке софта под «онтопик» говорят делать это. Не знаю, почему вообще кто-то считает это хорошей идеей (могут быть, наверное, исключения, но не советовать же это в качестве стандартного способа установки). Если пакета под ваш дистрибутив нет, используйте Flatpak, AppImage, AUR, PPA, Docker или хотя бы tar.gz, распакованный в пользовательскую директорию. (Snap не используйте, Snap — говно.)
2. sudo gedit .
В основном в «гайдах» по настройке чего-то на «бубунте». Ибо пишут эти такие же «бубунтята». Консольный текстовый редактор и то такая себе идея от рута запускать. Hint: man sudoedit .
3. « / на SSD, $HOME на HDD».
Почему-то у линуксоидов так сложилось, что принадлежащие пользователю файлы хранятся в одной куче с данными, пренадлежищими программам. Из-за этого остаётся либо выключать в ФМ показ скрытых файлов (а потом снова вклюать, когда понадобится, после чего снова отключать), либо лицезреть помойку. Но самое страшное последствие данного маразма проявляется, когда у пользователя имеется SSD и HDD и он решает на первый поставить систему, а на второй вынести $HOME . В итоге данные, которые по назначению совпадают с содержимым / (только являются при этом специфичными для конкретного пользователя), которые программы постоянно читают и перезаписывают, оказываются на HDD. Храните свои пользовательские данные в /data/ (как в андроиде), /mnt/data/ или где-то ещё. А $HOME пусть остаётся на SSD, на том же разделе, что и / . (Хранить все данные исключительно на HDD тоже не обязательно.) Местоположение папок «Загрузки», «Документы», «Изображения» и т. д. можно настроить средствами DE либо через конфиг XDG User Directories.
4. gremlin_the_red пишет по поводу CONFIG_HZ=1000 для плавности:
Ммм, карго культ он такой. Это очень много лет, как абсолютно ничего не даёт. […] В нашей реальности 2021го не осталось шедулеров, привязанных к config_hz, это дела давно минувших дней.
5. Отдельный раздел для swap.
Зачем лишний раз усложнять себе жизнь и плодить разделы, если можно сделать swap в виде файла? И нет, производительность от этого не упадёт. (Оказывается, что если HDD, то таки упадёт, но там, наверное, уже неважно (см. комментарии).)
Поделитесь успешными кейсами, когда вы вели разработку проектов целиком в виртуальной машине. Не так, шоб vagrant вместо девопса, а прям по жести: виртуалка с операционкой, операционка с гуями, внутри нее IDE (настоящая, а не вим, саблайм или вскод) и прочий тулинг.
Я сейчас тестирую на себе такой подход: каждый проект в своей виртуалке. На виртуалке Xubuntu 20.04. Каждой виртуалке по 8 гигов ОЗУ и 4 ядра (из 8 возможных). Из тяжелой техники: пайчарм, вебшторм, пхпшторм, nvm + npm, доцкер.
В целом, полёт нормальный (пока npm не начал качать половину инета и не занял всю ОЗУ).
Короче, я не издеваюсь, а хочу больше удобств для разработке множества разных по составу проектов. Одним лишь докером сыт не будешь, как говорится, плюс есть нюансы в плане пересечений версий приложений.
Вообщем, я тут буду вас пытаться убедить, что это удобно, а вы меня покритикуйте. Может я за 10 лет работы упоролся в край и делаю не то. Может стоит тупо прикупить еще пару SSD и раскатать пару ОС в мультибут.
Очень часто здесь говорится, в основном в контексте обсуждения gentoo, что при сборке можно получить значительную оптимизацию, но это не -Ofast -march=native и ее нужно уметь готовить.
Однако везде говорится что -Ofast -march=native вполне достаточно, все остальное - лишнее, а иногда и вредное
Временные таблицы (диск) 34.65% Процент временных таблиц потребовавших создание на диске (Created_tmp_disk_tables / (Created_tmp_tables + Created_tmp_disk_tables)). Процент более 30% и требуется увеличить параметры tmp_table_size (текущее значение: 64 МБ) и max_heap_table_size (текущее значение: 64 МБ). Убедитесь, что значения этих параметров равны. Так же возможно требуется сократить количество SELECT DISTINCT запросов без LIMIT.
Кеш открытых таблиц 0.93% Эффективность кеша открытых таблиц (Open_tables / Opened_tables). Если значение эффективности менее 20%, то требуется увеличить значение параметра table_open_cache (текущее значение: 1024). Увеличивайте параметр постепенно чтобы избежать превышения лимитов на количество одновременно открытых файлов в операционной системе.
В общем эти 2 параметра поднимаю параметры, показатели улучшаются, но со временем падают и приходят в красный цвет, т.е. не оптимальны, что посоветуете?
вот с этим еще не ясно, что это, подскажите плз: Так же возможно требуется сократить количество SELECT DISTINCT запросов без LIMIT.
Есть сервер с конфигурацией
Процессор Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 3876.531 Mhz X 8
Оперативная память 3179284 / 32876156 kB
Размер дискового пространства 212975 Mb
Файл подкачки (swap) 12574716 kB
Средняя загрузка (1, 5, 15 мин) 1.06 0.57 0.40
Продолжительность работы 5 days 21 hours 25 minutes
Напрягают 2 параметра 1 работа почтового сервера - удалил стандартную, поставить postfix, стало 0.3 - все равно время медленее эталонного - но это фигня.
А вот параметры базы напрягают очень дико.
Вот настройки мускула
explicit_defaults_for_timestamp = 0
sql_mode=
transaction-isolation = READ-COMMITTED
innodb_flush_method = O_DIRECT
innodb_file_format = Barracuda
max_heap_table_size = 512M
tmp_table_size = 512M
innodb_buffer_pool_size=10G
innodb_additional_mem_pool_size=32M
innodb_file_io_threads=8
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_lock_wait_timeout=50
innodb_log_buffer_size=32M
innodb_flush_log_at_trx_commit=2
innodb_log_file_size=256M
innodb_file_per_table = 1
optimizer_search_depth = 0
join_buffer_size = 4M
key_buffer_size=16M
sort_buffer=8M
read_buffer_size=16M
query_cache_size=128M
query_cache_type=1
query_cache_limit = 64M
Кто что посоветует покрутить?
PS: Пожалуйста не нужно читать лекцию про то что это все попугаи, писькомерство и т.п. если мы об этом спрашиваю, значит мне нужны эти цифры(как минимум для клиентов).
Относительно базы данных рекомендую отказаться от innodb_file_per_table = 1 (чтобы все хранилось в одном файле ibdata), правда придется сдампить базы, затем отключить, переименовать /var/lib/mysql и переинцииализировать и снова залить mysql базы
Относительно почтовой системы разобраться что у вас настроено при отправке почты, возможно долго резолвится имя сервера если оправка по smtp, следовательно прописать записи в /etc/hosts к которым идет подключение или если медленный резровер настроить локальных bind и его прописать в /etc/resolv.conf
Относительно базы данных рекомендую отказаться от innodb_file_per_table = 1 (чтобы все хранилось в одном файле ibdata), правда придется сдампить базы, затем отключить, переименовать /var/lib/mysql и переинцииализировать и снова залить mysql базы
На сколько я помню дампить не обязательно, достаточно сделать для всех таблиц:
ALTER TABLE table_name ENGINE=InnoDB;
Относительно базы данных рекомендую отказаться от innodb_file_per_table = 1 (чтобы все хранилось в одном файле ibdata), правда придется сдампить базы, затем отключить, переименовать /var/lib/mysql и переинцииализировать и снова залить mysql базы
Относительно почтовой системы разобраться что у вас настроено при отправке почты, возможно долго резолвится имя сервера если оправка по smtp, следовательно прописать записи в /etc/hosts к которым идет подключение или если медленный резровер настроить локальных bind и его прописать в /etc/resolv.conf
А почему отказаться? Просто я наборот читал что функция очень полезна, на серваке около 15 сайтов, у половины из них база около гига - не будет ли обратного эффекта?
На сколько я помню дампить не обязательно, достаточно сделать для всех таблиц:
ALTER TABLE table_name ENGINE=InnoDB;
это если переконвертировать myisam в innodb, а если уже innodb каждая таблица в своем файле, то придется пересоздать, иначе-то как, я так делал.
Зато у innodb_file_per_table достоинства что при удалении баз данных (если на сервере не один-два сайта на битриксе) высвобождается место (а не многогигабатный ibdata файл который растет), да и повреждается в случае внезапных падений mysql/ребутах такая база значительно намного реже или пострадает одна табличка, а не перестает запускаться весь сервер
А почему отказаться? Просто я наборот читал что функция очень полезна, на серваке около 15 сайтов, у половины из них база около гига - не будет ли обратного эффекта?
В инструментах есть "базы данных" а далее в изменить, нигде в общем даже похожих настроек нету( у меня версия лайт, может поэтому.
такое возможно
Допишите их
В ISP тоже можно отредактировать
Раздел Инструменты -> Серверы баз данных -> Настройки
/etc/my.cnf
Те же индексы, если их 2 Мб, нет смысла выделять 10 Gb памяти, и так почти со всем параметрами
А может придумали какой ни-дь авто-оптимизатор для mysql? Например, задаёшь в конфиге сколько не жалко оперативки под работу MySQL'a, а он крутит параметры, так сказать, automysqltuner. До такого техника не дошла ещё?
да может что-то такое и есть
Но я пока доверяю своим глазам, рукам, логам и мониторингу с графиками
Читайте также: