Производительность

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

Android процесс [teei_switch_thr] постоянно нагружает процессор на 90-100%. [teei_switch_thr] - это вирус? Как отключить (удалить) teei_switch_thr или снизить его нагрузку на CPU?

Из предыдущих материалов мы знаем, что в движке Joomla 3.x и до Joomla 5.x входящие параметры в ссылках вовсе никак не фильтруются - это позволяет забомбить кэш добавляя в ссылку лишние параметры и/или случайным образом изменяя их значения.

Joomla имеет несколько вариантов кэширования контента: Системный кэш: Отключено; Стандартное кэширование; Прогрессивное кэширование; и плагин Система - Кэш (system / cache).

Сегодня нам пишут, что в ПрестаШопе админка повесилась: при переходах между страницами в админ.панели PrestaShop начали появляться провалы во времени, задержки около 15-20 сек.

На сайте с включённым кэшем были замечены множественные нежелательные и причудливые параметры в ссылках постраничной навигации. Глюк относительно старый, но многими уже малость подзабытый.., и может ли он быть связан с переполнением кэша на сайте?

Nginx по команде service nginx restart слишком долго перезапускается, более часа...

Кто бы мог подумать, что Read Look-Ahead и read-ahead (readahead) могут оказаться страшнейшим багом, а не фичей! Баг сей ярко выражен в жутком свопинге, когда выполняется чтение больших файлов, в результате которого всё встаёт колом на одном месте без движений в какую либо сторону.

История про дэбаг геморроя с гига-кешем com_k2_extended, куда может деваться свободное место на сервере и про способы поиска источника проблемы. В некоторых особо запущенных случаях с поиском причины утечки места на диске могут возникнуть проблемы, например когда команда du -shc повесилась

Планировалось на андроиде поднять squid сервер с файловым кешем на диске и раздавать между браузерами для экономии трафика, но squid из репозитория termux оказался кастрированный ;(

Веб-браузер Google Chrome выдаёт ошибку DNS_PROBE_FINISHED_NXDOMAIN о проблеме с DNS именем при попытке открыть некий веб-сайт, но при работе с другими доменами никаких проблем нет.

Длиннющие имена файлов, пустые строки, абзацы табуляцией, заголовки по центру, за-span-енный текст, цвет и размер шрифта, а также другие излишние атрибуты качественной ХТМЛ разметки текста.

Люди скоты, веб-мастера дебилы, гугол паскуда.., - и ты попробуй всем им пид@р@с@м докажи, что ты не робот.

Механизм обновления ОС Дебиан оставляет желать лучшего. После обновления Debian 9 (stretch) до Debian 10 (booster) система начала жрать почти в три раза больше оперативной памяти (ака ОЗУ), X11 спустя какое-то время после перезагрузки отваливался, на "клаву" с "мышью" ноль реакции, и так после каждой перезагрузки, которых было около 10.

ngx_pagespeed модуль полезный, но со своими "завихами". Можем получить "HTTP 404 Not found" при попытке открыть в браузере оригинальный файл изображения jpg/jpeg/png/gif в имени которого после расширения имеется суфикс ".pagespeed.", например "origin_file_name.jpg.pagespeed.ce.LJC2ixTs0v.jpg".

Для для веб-серверов Nginx и Apache существует модуль оптимизации контента, который в свою очередь в уже оптимизированном виде кэшируется в директорию по-умолчанию "/var/cache/pagespeed/", а устаревшие файлы кэша могут доставлять неудобства при регулярном обновлении скриптов.

Перевыделение (overcommitting) оперативной памяти в Linux, особенно на рабочих серверах, является величайшим Злом, и это Зло в Linux разрешено по-умолчанию - vm.overcommit_memory=0

page-cluster довольно интересный и важный параметр настройки подсистемы виртуальной памяти (VM) ядра Linux, от правильного понимания механизма работы которого зависит стабильность и производительность машины с относительно малым размером оперативной памяти и активно использующей "подкачку страниц" (paging, ошибочно swapping) с резервного хранилища (жесткого диска).

На последнем ядре kernel-2.6.32-754.10.1.el6.i686 в "голой" CentOS 6.10 (CentOS-6.10-i386-minimal.iso), установленной на Virtualbox 5.2.x (OS Debian 9, 2 GB RAM, CPU Intel Pentium 3.2 ГЦ), работать практически невозможно, время от старта до полной загрузки 13-15 мин (обоср@ца-eб@нуца)!

С самого начала покупки VPS от Creanova на 2-3 день использования начались проблемы с производительностью дисковых I/O операций, IOWAIT зашкаливало, пропускная способность операций чтения/записи обещанного SSD упала ниже возможностей обычного HDD (тест выполнялся после перезагрузки и при отключенных веб сервисах).