1. Приветствую гостей и пользователей нашего форума! Первый раз вы у нас или же давно участвуете в жизни ресурса, хочу напомнить несколько моментов.

    1) Пользуемся поиском по форуму! Зачастую информация может находиться не по разделу!

    2) Раздел ИНФО-продуктов относительно новый, но имеем уже более 3000 высококлассных материалов (пользуемся сортировкой по прификсам).

    3) И самое важное, КАК КАЧАТЬ БЕЗ ОГРАНИЧЕНИЙ, вся информация находится по этой ссылке КУПИТЬ VIP

    4) Временная акция, получи +5 постов за вступление в нашу группу "Вконтакте" Более подробно ТУТ

    5) Веди активную жизнь на форуме и получай рубли на личный счёт!

    Скрыть объявление
  2. На нашем форуме Null-Prog действует серьёзное правило касательно размещения материалов!

    ДЛЯ РЕЛИЗЁРОВ: категорически запрещается выкладка материалов на файлообменники типа Deposit, letitbit и другие, требующие просмотров рекламы, обрезающие скорость и тд. Нарушителям, первые 2 раза предупреждения, далее БАН. Тему по этому поводу можно посмотреть ТУТ

    Скрыть объявление
  3. В тестовом режиме на нашем форуме открыт онлайн конструктор сайтов. Вы можете попробовать создать свой сайт у НАС, интуитивно понятный интерфейс, переведёт на 95%, быстрый экспорт проекта, от вас только перетаскивать элементы и вставить в них необходимый текст!

    Все вопросы ТУТ

    Скрыть объявление

  4. Скрыть объявление
  5. Уважаемые форумчане, открывается новый раздел форума, посвящённый ремонту и эксплуатации автомобилей. Просмотреть его можно ТУТ

    Так как раздел новый, информация будет пополнять каждый день. Если есть какие либо замечания по этому разделу, отписываемся в соответствующий раздел форума, либо в личку.

    Напоминаю, сообщения в разделе АВТО не учитываются, общение не ограничено.

    Скрыть объявление
  6. Объявляется набор Модераторов на различные раздел форума, свои заявки можно оставлять в ЭТОМ разделе, перед оставлением заявки рекомендуется ознакомиться с ПРАВИЛАМИ для модераторов.

Важно ОПТИМИЗАЦИЯ

Тема в разделе "Linux", создана пользователем Sam Jack, 3 июн 2015.

  1. Sam Jack

    Sam Jack Капитан-Узурпатор
    Команда форума Созидатель

    Регистрация:
    5 май 2015
    Сообщения:
    13.755
    Симпатии:
    4.749
    [​IMG]

    Эта статья проведет вас через различные шаги настройки вашего VDS и файловой системы под конкретный тип процессора, объем памяти и сеть.

    Заранее предупреждаю что данная оптимизация подразумевает редактирование критически важных параметров системы(ядра)
    и одно не верное значение может уложить систему по этому всегда делайте копии тех конфигов прежде чем что либо в них изменять.
    А лучше на домашней машине развените виртуальную машину например VirtualBox и сначала проэкспеременируйте там плюсом такого варианта является безопасность и возможность проводить любые экспирименты над LINUX и только после того как вы добетесь стабильности и повышенного быстродествия только после этого применяйте это на своем VDS. Имено так я всегда и делаю.

    Такие настройки используются для серверов, позволяя повышать их быстродействие.

    Первое, что мы будем изменять, это файл /etc/profile. Файл /etc/profile содержит системное окружение всех исполняемых программ. Все настройки, добавленные в этот файл, отражаются на переменные окружения вашей системы. Так, поместив в этот файл флаги оптимизации, мы получим увеличение производительности компилируемых программ. Чтобы выжать максимальную эффективность из ваших программ, при компиляции вы можете использовать флаг -09, обозначающий полную оптимизацию по скорости. В Makefile многих программ, которые вы компилируете, содержится опция -02. Но, поставив вместо нее -09, мы получим высший уровень оптимизации, при которой размер файла увеличивается, но увеличивается и скорость выполнения.
    Замечание. Использование опции -09 не всегда приводит к наилучшим результатам. Опцию следует использовать для процессоров x686 и выше, но не для более старых процессоров.
    Также при компиляции можно использовать опцию -fomit-frame-pointer, которая говорит, что для доступа к переменным нужно использовать стек. К сожалению, с этой опцией практически невозможна отладка. Также можно использовать переключатели -mcpu=cpu_type и -march=cpu_type, при помощи которых создается код, оптимизированный под определенный CPU. Полученный код будет работать только на заданном процессоре или более новом.

    Итак, приведенные ниже оптимизационные флаги запишем в файл /etc/profile (они влияют только на программы, которые вы будете компилировать в дальнейшем, и не оказывают никакого действия на существующие файлы):
    ? для CPU i686 или PentiumPro, Pentium II, Pentium III в файл "/etc/profile" добавьте следующую строку: CFLAGS='-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions'
    ? для CPU i586 или Pentium в файл "/etc/profile" добавьте следующую строку: CFLAGS='-O3 -march=pentium -mcpu=pentium -ffast-math -funroll-loops -fomit-frame-pointer -fforce-mem -fforce-addr -malign-double -fno-exceptions'
    ? для CPU i486 в файл "/etc/profile" добавьте следующую строку: CFLAGS='-O3 -funroll-all-loops -malign-double -mcpu=i486 -march=i486 -fomit-frame-pointer -fno-exceptions'

    Сразу же после выбора типа процессора добавим в строку export файла "/etc/profile" переменные "CFLAGS LANG LESSCHARSET":
    export PATH PS1 HOSTNAME HISTSIZE HISTFILESIZE USER LOGNAME MAIL INPUTRC CFLAGS LANG LESSCHARSET
    Теперь выйдите из системы и вновь в нее войдите, чтобы опции, определенные переменной CFLAGS, вступили в силу и все программы и другие configure-утилиты стали ее учитывать. Оптимизация под Pentium (Pro/II/III) будет работать только с компиляторами egcs и pgcc. Egcc уже входит в стандартную поставку Linux. Ниже приведено описание опций, которые мы использовали:
    -funroll-loops ? выполняется оптимизация развертыванием циклов. Осуществляется для циклов, число итераций которых может быть определено во время компиляции или во время выполнения.
    -funroll-all-loops ? выполняется оптимизация развертыванием циклов. Развертывает все циклы, и обычно программы, скомпилированные с этой опцией, медленнее запускаются.
    -ffast-math ? эта опция разрешает GCC нарушать некоторые ANSI или IEEE правила и/или спецификации в интересах оптимизации кода по скорости выполнения. Например, это позволяет компилятору предполагать, что параметры к функции sqrt ? неотрицательные числа.
    -malign-double ? контролирует, выравнивает ли GCC double, long double и long long переменные на двусловной границе или однословной границе.

    Выравнивание double переменных на двусловной границе создает код, который выполняется на Pentium-процессорах несколько быстрее, расходуя больше памяти.
    -mcpu=cpu_type ? определяет значение типа процессора при планировании используемых инструкций. При определении конкретного типа CPU, GCC будет использовать инструкции специфичные для него. Если эта опция не определена, то будут использоваться только команды, работающие на i386 процессоре. Тип процессора I586 эквивалентен Pentium, i686 эквивалентен Pentium Pro, K6 ? AMD.
    -march=cpu_type ? использовать инструкции для процессора cpu_type. Выбор типа процессора производится так же, как и для опции mcpu. Кроме того, использование опции -march=cpu_type подразумевает и использование опции -mcpu=cpu_type.
    -fforce-mem ? принуждает копировать операнды, хранящиеся в памяти, в регистры перед выполнением арифметических операций над ними. В результате получается более лучший код, в котором все ссылки на ячейки памяти потенциально общие подвыражения. Когда они не являются общими подвыражениями, то комбинации команд должны устранить отдельную загрузку регистра.
    -fforce-addr ? вынуждает копировать постоянные адреса памяти в регистры перед выполнением арифметических операций над ними. В результате может создаваться более хороший код, так же как и при -fforce-mem.
    -fomit-frame-pointer ? не сохранять frame pointer в регистре для функций, которые не нуждаются в этом. Это позволяет избежать инструкций на сохранение, определение и восстановление frame pointer, в то же время освобождая регистры для других функций. Это также делает невозможным отладку программы.

    Следующее, на что стоит обратить внимание, это файл bdflush. Он вплотную связан с операциями в подсистеме виртуальной памяти ядра Linux и имеет некоторое влияние на использование диска. Этот файл (/proc/sys/vm/bdflush) контролирует операции демона ядра bdflush. Мы используем этот файл для улучшения производительности файловой системы. Изменяя некоторые значения в файле, принятые по умолчанию, мы добьемся, чтобы система стала более "отзывчивой", например, она ждет чуть больше при осуществлении записи на диск, что позволяет таким образом избегать некоторых конфликтов доступа.
    За основу возьмем Red Hat Linux. По умолчанию bdflush в Red Hat Linux использует следующие значения: "40 500 64 256 500 3000 500 1884 2".

    Для изменения значений в bdflush введите следующие команды на вашем терминале:
    echo "100 1200 128 512 15 5000 500 1884 2">/proc/sys/vm/bdflush

    Вы можете добавить эту команду в /etc/rc.d/rc.local, чтобы она выполнялась каждый раз при загрузке компьютера. Для более свежих дистрибутивов следует использовать другой способ: в файл /etc/sysctl.conf добавьте следующую строку:
    vm.bdflush = 100 1200 128 512 15 5000 500 1884 2

    Чтобы изменения вступили в силу, надо перезагрузить систему.
    В вышеприведенном примере согласно файлу документации /usr/src/linux/Documentation/sysctl/vm.txt первый параметр в % определяет максимальное число "грязных" буферов в кэше буферов. "Грязные" означают то, что содержимое буфера должно быть записано на диск. Присвоение этому параметру высокого значения означает, что Linux в течение долгого времени может задерживать запись на диск, но в то же время это означает, что когда это все же потребуется, то сброс всех буферов будет осуществляться дольше, т.к. самих "грязных" буферов будет больше. Низкое значение будет распределять операции ввода-вывода более равномерно.

    Второй параметр (ndirty), которому мы присвоили значение 1200, определяет максимальное число "грязных" буферов, которые могут быть одновременно записаны. Высокое значение означает как бы отложенные, пульсирующие операции ввода-вывода, в то время как маленькое значение может приводить к нехватке памяти.

    Третье значение (nrefill=128) определяет число буферов, которые bdflush будет добавлять в список свободных при вызове функции refill_freelist(). Чем выше число, тем больше памяти будет потрачено впустую и тем реже будет необходимо вызывать refill_freelist().

    Следующий параметр ? nref_dirt=512. Когда refill_freelist() натолкнется на больше, чем nref_dirt "грязных" буферов, то просыпается демон bdflush.
    Параметры age_buffer (50*m) и age_super parameters (5*m) обозначают максимальное время, которое Linux ждет перед записью грязных буферов на диск. Значение выражено в мигах (clockticks), число мигов в секунду m=100. Как описывается в английской литературе, "age_buffer это "возраст" блоков данных, а age_super ? "возраст" метаданных файловой системы" (дословный перевод).

    Пятый параметр (15) и последние два (1884 и 2) не используются системой, так что мы оставим их значения по умолчанию.
    Замечание. Читайте /usr/src/linux/Documentation/sysctl/vm.txt о том, как улучшить параметры ядра, связанные с виртуальной памятью.

    Файл buffermem. Этот файл тесно связан с работой подсистемы виртуальной памяти Linux ядра. Значения в этом файле (/proc/sys/ vm/buffermem) контролируют, как много памяти используется под буферную память (в процентах). Следует отметить, что проценты берутся от общей системной памяти. Значение по умолчанию в buffermem для Red Hat:
    "20 10 60"
    Для изменения значений параметров используйте следующие команды:
    echo "80 10 60" >/proc/sys/vm/ buffermem
    Вы можете добавить эту команду в /etc/rc.d/rc.local, чтобы она выполнялась каждый раз при загрузке компьютера. Или отредактируйте файл "/etc/sysctl.conf" и добавьте следующую строку:
    vm.buffermem = 80 10 60
    Чтобы изменения вступили в силу, стоит перезагрузить систему.
    В вышеприведенном примере согласно файлу документации /usr/src/linux/Documentation/sysctl/vm.txt первый параметр (80%) говорит использовать минимум 80% системной памяти под буферный кэш (минимальное число процентов памяти, которое должно быть использовано под буферную память). Последние два параметра (10 и 60) не используются системой, и мы их оставляем без изменений.
    Замечание. О том, как улучшить параметры ядра, связанные с виртуальной памятью, читайте в файле /usr/src/linux/Documentation/sysctl/vm.txt.


    Файл ip_local_port_range. Этот файл содержит два целых числа, определяющих интервал портов, которые используют TCP и UDP при выборе локального порта. Первое число ? это нижнее возможное значение, а второе ? верхнее. В серверных системах эти числа имеют значения 32768 и 61000 соответственно. По умолчанию в Red Hat файл ip_local_port_range содержит значения "1024 4999". Чтобы изменить эти значения, используйте следующие команды:
    echo "32768 61000" > /proc/ sys/net/ipv4/ip_local_port_range
    Вы можете добавить эту команду в /etc/rc.d/rc.local, чтобы она выполнялась каждый раз при загрузке компьютера. Или отредактируйте файл /etc/sysctl.conf и добавьте следующую строку:
    net.ipv4.ip_local_port_range = 32768 61000
    Чтобы изменения вступили в силу, стоит перезагрузить систему.

    Файл /etc/nsswitch.conf. Этот файл используется для настройки того, какой сервис использовать для получения такой информации, как имя хоста, файл паролей, файл с группами и т.д. Два последних пункта (файл с паролями и файл с группами) рассматриваться не будут. Таким образом, акцентируем наше внимание на строке hosts. Отредактируйте файл nsswitch.conf и измените строку hosts, чтобы она читалась:
    hosts: dns files
    которая говорит программам, желающим определить адреса, что вначале необходимо воспользоваться службой DNS, а затем, если DNS не отвечает, файлом "/etc/hosts". Также настоятельно рекомендуется удалить все вхождения NIS из каждой строки, если вы не используете NIS. В результате файл /etc/nsswitch.conf может выглядеть следующим образом:
    passwd: files
    shadow: files
    group: files
    hosts: dns files
    bootparams: files
    ethers: files
    netmasks: files
    networks: files
    protocols: files
    rpc: files
    services: files
    automount: files
    aliases: files

    Файл file-max. Значение в этом файле определяет максимальное число дескрипторов файлов, которые может распределить ядро. Мы настраиваем этот файл на увеличение числа открытых файлов. Для серверных систем рекомендуется следующее правило: увеличьте значение /proc/sys/fs/file-max до значения примерно равного 256 на каждые 4M RAM, например, для машины со 128 M установите значение равное 8192 (128/4=32, 32*256=8192). По умолчанию в Red Hat file-max равен 4096. Чтобы изменить эти значения, используйте следующие команды:
    echo "8192" >/proc/sys/fs/file-max
    Вы можете добавить эту команду в /etc/rc.d/rc.local, чтобы она выполнялась каждый раз при загрузке компьютера. Или отредактируйте файл "/etc/sysctl.conf" и добавьте следующую строку:
    fs.file-max = 8192
    Чтобы изменения вступили в силу, стоит перезагрузить систему.
    Замечание. Когда вы начинаете получать много ошибок о выходе за пределы файловых дескрипторов (running out of file handles), увеличьте значение file-max. Файловому и веб-серверам нужно много открытых файлов.

    Файл inode-max. Этот файл (/proc/sys/fs/inode-max) определяет максимальное число дескрипторов блоков индексов (inode). В нашем примере мы настраиваем этот файл на увеличение числа открытых блоков индексов (inode), увеличивая "/proc/sys/fs/inode-max" до значения в 3-4 раза большего (8192*4=32768) числа открытых файлов (file-max). Это обусловлено тем, что на каждый открытый файл приходится как минимум 1 блок индекса, а для больших файлов ? намного больше. По умолчанию в Red Hat inode-max равен 16376. Чтобы изменить эти значения, используйте следующие команды:
    echo "32768" >/proc/sys/fs/ inode-max
    Вы можете добавить эту команду в /etc/rc.d/rc.local, чтобы она выполнялась каждый раз при загрузке компьютера. Или отредактируйте файл /etc/sysctl.conf и добавьте следующую строку:
    fs.inode-max = 32768
    Чтобы изменения вступили в силу, стоит перезагрузить систему.
    Замечание. Если вы регулярно получаете сообщение run out of inodes, то вам необходимо увеличить значение inode-max. Помните, что этот параметр зависит от file-max. Файловому и веб-серверам требуется много открытых индексных блоков.

    Параметр ulimit. Linux имеет ограничение "Max Processes" для каждого пользователя. Этот параметр показывает, как много процессов может иметь пользователь. Для улучшения производительности вы можете спокойно увеличить это значение для пользователя root, сделав его неограниченным. Добавьте следующую строку в файл /root/.bashrc:
    ulimit -u unlimited
    Теперь вы должны перелогиниться (сделать logout и login). Для проверки, что вы все сделали правильно, дайте команду (как root):
    ulimit -a
    в строке с max user processes должен быть текст "unlimited".
    Увеличим также системные ограничения на открытые файлы. Процесс в Red Hat 6.0 с ядром 2.2.5 может открыть не меньше 31000 файловых дескрипторов и процесс на ядре 2.2.12 ? не меньше 90000 файловых дескрипторов (согласно установленным ограничениям). Верхняя граница зависит от доступной памяти. Увеличение этого числа до 90000 для пользователя root делается следующим образом: отредактируйте файл /root/.bashrc, добавив следующую строку:
    ulimit -n 90000
    Теперь вы должны перелогиниться. Для проверки, что вы все сделали правильно, дайте команду (как root):
    ulimit -a
    в строке с open files должен быть текст "90000".

    Атрибут atime (access time). В дополнении к информации о дате создания и последней модификации файла, Linux создает запись о последнем обращении к файлу. Эта информация не очень полезна и при этом происходят затраты системных ресурсов на ее ведение. Файловая система ext2 позволяет суперпользователю маркировать отдельные файлы, чтобы запись о времени последнего доступа к ним не велась. Это может существенно улучшить эффективность системы, особенно, если установить этот атрибут для часто используемых файлов, например, для /var/spool/news. Для установки атрибута на один файл используется команда:
    chattr +A filename
    Для всех файлов в каталоге:
    chattr -R +A /var/spool/
    Для снятия же атрибута надо писать не +A, а -A.

    Атрибут noatime. Linux имеет опцию монтирования файловой системы, называемую noatime. Она может быть добавлена в поле опций файла /etc/fstab. Если файловая система смонтирована с этой опцией, то при доступе к ней по чтению информация atime изменяться не будет. Важность установки опции noatime в том, что она устраняет необходимость операции записи в файловую систему для файлов, которые просто читаются. Так как запись "дорогая" операция, то ее отсутствие может существенно улучшить эффективность системы. Обратите внимание, что информация wtime продолжает изменяться при записи в файл. В нашем примере мы устанавливаем опцию noatime для файловой системы /mnt/linux_games. Отредактируйте файл /etc/fstab и добавьте, например, такую строку:
    /dev/hda7 /mnt/linux_games ext2 defaults,noatime 1 2
    Перезагрузите вашу систему и проверьте, что у вас получилось:
    reboot
    cat /proc/mounts
    В результате одной из строк, выводимых на экране, должна быть
    /dev/hda7 /mnt/linux_games ext2 rw,noatime 0 0
    Мы видим, что /mnt/linux_games имеет атрибут noatime.

    Swap-раздел. Поместите ваш swap-раздел вблизи начала вашего диска, которое физически располагается на внешней стороне цилиндра. В результате за один оборот головка охватывает большую поверхность. При помощи команды hdparm -t я вижу, что с разделом, помещенным в конце диска, скорость работы на 3 MB/s медленнее.

    Настройка производительности IDE-дисков. Быстродействие IDE-дисков увеличивается при использовании UDMA. Ядро использует консервативный режим работы с дисками, пока ему не скажешь изменить это. "Волшебная" команда для изменения установок ? это hdparm. Включение 32-bit I/O через шину PCI:
    /sbin/hdparm -c 1 /dev/hda (или hdb, hdc и т.д.)
    Руководство man для hdparm говорит, что для некоторых чипсетов нужно использовать "-c 3". Все (E)IDE диски до сих пор имеют 16-разрядное подключение через ленточный кабель к интерфейсной карте. Включение DMA:
    /sbin/hdparm -d 1 /dev/hda (или hdb, hdc и т.д.)
    Возможность использования этой команды зависит от поддержки чипсета вашей материнской платы ядром. При включении DMA отменяется синхронизация буферизированного чтения диска, в результате чего быстродействие может увеличиться в 2 раза. Для включения multiword DMA mode 2:
    /sbin/hdparm -d 1 -X34 /dev/ hda (или hdb, hdc и т.д.).
    Эта установка используется для (E)IDE/ATA2 дисков (посмотрите документацию к вашему диску). Для включения UltraDMA mode2:
    /sbin/hdparm -d 1 -X66 /dev/ hda (или hdb, hdc и т.д.)
    Вам нужно будет заранее подготовить ваш чипсет к использованию UltraDMA, так что прочитайте man-ы к hdparm. Используйте этот режим очень осторожно!
    Для включения multiple sector mode I/O:
    [root@deep]# /sbin/hdparm -m XX /dev/hda (или hdb, hdc и т.д.)
    где "XX" ? максимальные установки, поддерживаемые вашим диском. Для поиска максимальных значений установленных жестких дисков может использоваться флаг -i (в выводимой информации смотрите значение MaxMultSect).

    Многосекторный режим (IDE Block Mode) поддерживается большинством современных IDE жестких дисков, передача нескольких секторов за одно I/O прерывание быстрее, чем обычное односекторное. Когда эта возможность включена, обычно, понижаются "накладные расходы" на операциях ввода/вывода на 30-50%. На многих системах в результате также увеличивается пропускная способность от 5% до 50%. Вы можете проверить, чего добились, запустив hdparm в режиме проверки производительности:
    /sbin/hdparm -t /dev/hda (или hdb, hdc и т.д.)
    Как только вы определили все параметры hdparm, не забудьте добавить соответствующие команды в файл /etc/rc.d/rc.local.

    Последнее, что мы сделаем, это заставим Linux обрабатывать большее число TCP/IP соединений за определенное время. Нижеописанные настройки уменьшают время TCP/IP подключения, чтобы можно было обработать больше соединений за тот же интервал. Также будет уменьшено время, которое Linux ждет до закрытия соединения, и время, через которое Linux разрывает устаревшее соединение. Эти настройки отключат некоторые расширения протокола TCP/IP, которые нам не нужны. Значения параметров TCP/IP стека, принятые в Red Hat по умолчанию:
    tcp_fin_timeout "180"
    tcp_keepalive_time "7200"
    tcp_window_scaling "1"
    tcp_sack "1"
    tcp_timestamps "1"
    Чтобы изменить параметры TCP/IP, используйте следующие команды:
    echo 30 > /proc/sys/net/ipv4/ tcp_fin_timeout
    echo 1800 >/proc/sys/net/ipv4/ tcp_keepalive_time
    echo 0 > /proc/sys/net/ipv4/ tcp_window_scaling
    echo 0 > /proc/sys/net/ipv4/ tcp_sack
    echo 0 > /proc/sys/net/ipv4/ tcp_timestamps
    Вы можете добавить эти команды в /etc/rc.d/rc.local, чтобы они выполнялись каждый раз при загрузке компьютера. Или отредактируйте файл /etc/sysctl.conf и добавьте следующие строки:
    net.ipv4.tcp_fin_timeout = 30
    net.ipv4.tcp_keepalive_time = 1800
    net.ipv4.tcp_window_scaling = 0
    net.ipv4.tcp_sack = 0
    net.ipv4.tcp_timestamps = 0
    Чтобы изменения вступили в силу, стоит перезагрузить систему.
    Мы рассмотрели некоторые ухищрения, которые помогают заоптимизировать систему.

    Теперь можно приступить к освобождению памяти.
    Начнем с ядра. Все ядра Linux, которые поставляются вместе с дистрибутивами, раздуты и поддерживают множество возможностей, которые вам могут никогда не понадобиться. Если вы еще не пересобирали ядро, то можете попробовать это сделать, но здесь нужен трезвый ум и полное понимание того, что делаешь. Существуют множество прекрасных книг и руководств по Linux, которые также рассказывают об этом.
    Если вы пересобираете ядро, запомните, что совсем не надо использовать все возможности ядра. Например, как часто вы включаете, к примеру, поддержку PLIP в ядро? Как часто вы будете это использовать? Маленькое ядро требует меньше времени для загрузки, меньше памяти и меньше загружает процессор.
    Другая важная вещь в ядре ? модули. Использование модулей позволяет не держать код ядра, который реализует какую-нибудь фишку, в памяти, а подгружать его только тогда, когда это необходимо.
    Виртуальные консоли ? это прекрасный путь освободить память. Большинство дистрибутивов Linux запускают около 6 виртуальных консолей ? именно между ними вы переключаетесь, используя комбинации Alt+F1 ? Alt+F6. В среднем, использование 6 консолей требует около 4 Мб памяти. Если убрать пару консолей, можно освободить пару мегабайт памяти. Большинство пользователей используют 3-4 консоли. Например, я использую только две. Сколько консолей вы оставите ? это ваше личное дело. Просто запомните, что чем меньше виртуальных консолей вы используете, тем больше памяти остается для работающих приложений. Количество используемых консолей описывается в файле /etc/inittab. Для того чтобы убрать виртуальную консоль, загрузите /etc/inittab в текстовый редактор, найдите строки, похожие на:
    c1:12345:respawn:/sbin/getty tty1 38400 linux
    c2:12345:respawn:/sbin/getty tty2 38400 linux
    Начиная с наибольшего номера (например, c6), закомментируйте строку, поставив знак '#' в начале строки. Повторите этот шаг столько раз, сколько вам нужно. Запомните, каждая закомментированная строка убирает одну виртуальную консоль. Перезапустите систему, чтобы изменения вступили в силу.
    Большинство дистрибутивов Linux запускают множество демонов (что это такое, грубо говоря это типа сервисов, как в Win2k, но только лучше), которые никогда не используются. Чаще всего они запускаются через скрипты. Где находятся скрипты и какие из них запускаются, зависит от дистрибутива. Чаще всего их можно найти в /etc/rc.d/rc.*.

    Прежде чем продолжить, стоит сказать, что вам было бы неплохо уметь писать скрипты. Для тех, кто уже знаком со скриптами, напомню, что скрипт должен начинаться со строки "#!/bin/sh" или подобной, после которой каждая строка запускается командным интерпретатором так, как будто она была введена с клавиатуры (так что скрипт ? не что иное, как простые макросы клавиатуры).
    Строки, начинающиеся с '#', являются комментариями и не исполняются. Большинство скриптов запуска демонов выглядят следующим образом:
    if условие then
    что-то
    fi
    Все, что мы хотим сделать ? это закомментировать строки между if и fi.
    Для того чтобы найти скрипт, в котором запускается демон, нужно поискать скрипт на предмет наличия в нем названия демона. Если я хочу найти, где запускается inetd, то должен сделать следующее:
    cd /etc/rc.d
    grep -n inetd rc.*

    Кратко перечислю демоны, которые можно удалять (список не претендует на полноту и достаточность):
    ? lpd ? используется для печати файлов на принтере командой lpr. Если вы не пользуетесь печатью на своей машине, то можете убрать lpd;
    ? nfsd и mountd ? это два демона, образующие NFS сервер. Если вы не используете свою машину как NFS сервер, то можете спокойно убрать эти два демона;
    ? portmap ? этот демон используется для поддержки сервиса RPC. Если вы не используете NFS или любую другую программу, использующую RPC, то можете убрать portmap;
    ? sendmail ? это еще один демон, требующий достаточно много памяти. Если вы не используете свою машину в качестве почтового сервера, то можете убрать sendmail. Если вы пользуетесь электронной почтой, то программу чтения почты можно настроить на другой почтовый сервер.
    Могут быть также другие демоны в системе, которые вам не нужны. Удалите их, если они не нужны. Вы должны обязательно оставить только два демона ? это syslogd и klogd, которые ведут логи вашей Линукс-системы.

    В более новых дистрибутивах запуск демонов прописан другим способом. В etc/rc.d есть другие подкаталоги, каждый из которых соответствует определенному runlevel'у. Для отключения какого-либо сервиса достаточно удалить соответствующую символическую ссылку в нужном каталоге на скрипт, запускающий этот сервис. Все скрипты, как правило, лежат в /etc/rc.d/init.d. Стоит также заметить, что еще проще и удобнее делать отключение сервисов при помощи соответствующих конфигурационных программ: linuxconf, drakconf (для Mandrake Linux).
    Вот и все. Стоит заметить, что результат выполнения вышеописанных действий зависит лишь от того, насколько вы разобрались в Linux. Так что используйте эти принципы на свой страх и риск. А также побольше читайте документацию.
     
  2. Sam Jack

    Sam Jack Капитан-Узурпатор
    Команда форума Созидатель

    Регистрация:
    5 май 2015
    Сообщения:
    13.755
    Симпатии:
    4.749
    УСТАНОВКА, НАСТРОЙКА И ОПТИМИЗАЦИЯ ВЕБ-СЕРВЕРА НА DEBIAN

    Оптимизация apache

    Прежде всего включаем следующие модули:
    deflate, expires, headers, php5, rpaf (установить его если не настроен)

    Затем настраиваем виртуальные хосты:

    <Directory />
    Options FollowSymLinks
    AllowOverride All
    Order Allow,Deny
    Allow from all
    </Directory>
    NameVirtualHost *
    Listen *:80
    Include /etc/apache2/sites/


    Затем для каждого сайта добавляем свои файлы в /etc/apache2/sites/ следующего формата:

    <VirtualHost *>
    ServerName example.ru
    ServerAlias www.example.ru
    DocumentRoot /home/example.ru/docs/
    ErrorLog /home/example.ru/logs/error.log
    CustomLog /home/example.ru/logs/access.log combined
    </VirtualHost>


    Теперь перейдем к оптимизации. Добавляем файл /etc/apache2/conf.d/optimize (по рекомендациям webo.in):

    # добавляем Content-Type для всех файлов с расширением .gz
    AddEncoding gzip .gz
    # включаем сжатие для HTML- и XML-файлов
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    # и для иконок (об этом чуть ниже)
    AddOutputFilterByType DEFLATE image/x-icon
    # также для CSS- и javascript-файлов
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    # выставляем максимальную степень сжатия (если возникнут проблемы с
    # серверной производительностью, следует уменьшить до 7 или 1)
    DeflateCompressionLevel 9
    # и максимальный размер окна для архивирования
    DeflateWindowSize 15
    # отключаем архивирование для «проблемных» браузеров
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    # добавляем заголовок Vary для корректного распознавания браузеров,
    # находящихся за локальными прокси-серверами
    Header append Vary User-Agent
    # запрещаем кэширование на уровне прокси-сервера для всех файлов,
    # для которых у нас выставлено сжатие,
    <FilesMatch .*\.(css|js|php|phtml|shtml|html|xml)$>
    Header append Cache-Control: private
    </FilesMatch>
    #Устанавливаем Expires
    <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault "access plus 1 week"
    </IfModule>

    # Устанавливаем ETag
    FileETag MTime Size


    Можно переходить дальше.

    Оптимизация Nginx

    Первым делом заставляем apache слушать локальный нестандартный порт:

    Listen 127.0.0.1:8080


    И правим файл /etc/nginx/nginx.conf примерно так:

    user www-data;
    worker_processes 2;

    error_log /var/log/nginx/error.log;
    pid /var/run/nginx.pid;

    events {
    worker_connections 1024;
    }

    http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] $status '
    '"$request" $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "http_x_forwarded_for"';
    access_log /var/log/nginx/access.log;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 30;

    gzip on;

    server {
    listen 80;

    location / {
    proxy_pass http://127.0.0.1:8080/;
    proxy_redirect off;
    log_not_found off;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    client_max_body_size 10m;
    client_body_buffer_size 128k;

    proxy_connect_timeout 40;
    proxy_send_timeout 90;
    proxy_read_timeout 40;

    proxy_buffer_size 4k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;
    }
    }
    }


    Перезагружаем apache и nginx. Наблюдаем за уже значительным увеличением производительности.

    Оптимизация PHP

    После установки PHP, также устанавливаем eaccelerator. Затем правим php.ini

    max_execution_time = 30
    Сколько CPU-секунд может потреблять скрипт

    max_input_time = 60
    Как долго (в секундах) скрипт может ждать входных данных

    memory_limit = 32M
    Какое количество памяти (в байтах) может расходовать скрипт, прежде чем он будет убит. Для неслабых приложений следует устанавливать этот лимит больше 64M

    output_buffering = 4096
    Какое количество данных (в байтах) накапливается в буфере, прежде чем они будут отправлены клиенту


    Размер этих значений обычно зависит от приложения. Если вы принимаете от пользователей большие файлы, max_input_time может быть увеличен или в php.ini, или путем его переопределения в коде. Подобным образом, для программ, потребляющих большое количество CPU или памяти могут потребоваться более высокие значения. Цель состоит в том, чтобы уменьшить воздействие "прожорливой" программы, поэтому глобальная отмена этих настроек не рекомендуется. Другое замечание относительно max_execution_time: это относится ко времени, затраченному CPU на процесс, а не к абсолютному времени. Таким образом, программа, совершающая большое количество вводов/выводов и небольшое количество вычислений, может выполняться намного дольше, чем max_execution_time. max_input_time также может быть больше, чем max_execution_time.

    Количество записей, которые может сделать PHP, может настраиваться. В промышленной эксплуатации экономят место на диске, отменяя все журналы, кроме самых критических. Если журналы необходимы для диагностики проблем, вы можете вернуть то журналирование, которое необходимо. error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR включает журналирование, достаточное для выявления проблем, но удаляет из скриптов лишнюю информацию.

    Оптимизация MySQL

    Первым делом используем скрипты:
    MySQLtuner.sh и tuning-primer.sh. Следуя появляющимся инструкциям настраиваем my.cnf.

    Для правильной работы в кодировке utf8 в файле /etc/mysql/my.cnd настраиваем следующее (в соответствующих секциях):

    [client]
    port = 3306
    socket = mysql
    default-character-set=utf8

    [mysqld]
    port = 3306
    socket = mysql
    skip-locking
    init_connect='SET collation_connection = utf8_general_ci'
    init_connect='SET NAMES utf8'
    default-character-set=utf8
    character-set-server = utf8
    collation-server = utf8_general_ci
    [mysql]
    default-character-set=utf8
    key_buffer = 1M
    max_allowed_packet = 2M
    table_cache = 4
    sort_buffer_size = 64K
    read_buffer_size = 256K
    read_rnd_buffer_size = 256K
    net_buffer_length = 2K
    thread_stack = 64K
    query_cache_limit = 256K
    query_cache_size = 4M


    Проверять переменные можно этими запросами:

    show variables like "%character%";
    show variables like "%collation%";


    Чтобы задать кодироку по-умолчанию (напр. если была latin1):
    1. Для все БД:

    alter database DBNAME default character set utf8 collate utf8_general_ci


    Для таблицы:

    ALTER TABLE table_name CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;


    Кстати, Разница между utf8_general_ci и utf8_unicode_ci, в том, что utf8_unicode_ci поддерживает expansions, то есть сопоставление одного символа нескольким (например - в Германии ß = ss ). Т.е. применять utf8_unicode_ci нужно например для немецкого или китайского языков. Если на сайте будет только русский или английский, то достаточно utf8_general_ci, которая будет работать гораздо быстрее.
     
  3. Sam Jack

    Sam Jack Капитан-Узурпатор
    Команда форума Созидатель

    Регистрация:
    5 май 2015
    Сообщения:
    13.755
    Симпатии:
    4.749
    ОПТИМИЗАЦИЯ WEB-СЕРВЕРА:УСТАНАВЛИВАЕМ EACCELERATOR

    продолжаю облегчать жизнь серверу.
    eAccelerator – все мы знаем что при обращении к файлу пхп вэб сервер компилирует пхп файл в некую программу, которая в дальнейшем, что-то делает и выдаёт нам результат в виде html, ну и кто-то задумался(может отбукился ): “а зачем постоянно делать одну и туже работу – компилировать при каждом обращении один и тот же файл”, и вот eAccelerator берёт откомпилированный php файл и складывает во временную папку и когда пользователь обращается к очередному пхп файлу в дело вступает eAccelerator, который проверяет есть ли уже “готовый” запрашиваемый файл, если находит готовый то сразу запускает его, тем самым облегчает жизнь серверу (значительно снижает нагрузку на процессор) например у меня нагрузка в часы пик с 70% упала до 7-25%

    Очень рекомендую ставить на сайт с посещаемостью выше 1К + связку nginx+apache2.

    ставим php5-dev

    apt-get install php5-dev


    берём свежий дистрибутив с http://eaccelerator.net/
    распаковываем, заходим в извлечённый каталог

    phpize


    ./configure –enable-eaccelerator=shared


    make


    make install


    cd /etc/php5/conf.d


    Создаём конфигурационный файл для акселератора

    touch eacclerator.ini


    вставляем в него содержимое

    zend_extension = “/usr/lib/php5/20060613+lfs/eaccelerator.so”
    eaccelerator.shm_size = “0&#8243;
    eaccelerator.cache_dir = “/var/cache/eaccelerator”
    eaccelerator.enable = “1&#8243;
    eaccelerator.optimizer = “1&#8243;
    eaccelerator.check_mtime = “1&#8243;
    eaccelerator.debug = “0&#8243;
    eaccelerator.filter = “”
    eaccelerator.shm_max = “0&#8243;
    eaccelerator.shm_ttl = “0&#8243;
    eaccelerator.shm_prune_period = “0&#8243;
    eaccelerator.shm_only = “0&#8243;
    eaccelerator.compress = “1&#8243;
    eaccelerator.compress_level = “7&#8243;
    eaccelerator.allowed_admin_path = “/var/www/”


    создаю каталог для кэша

    mkdir /var/cache/eaccelerator


    chmod 777 /var/cache/eaccelerator


    теперь можно перезапустить apache

    для контроля над тех процессом есть файл control.php
    в нём находим логин пароль и перекидываем в нужную нам папку на территории вэб сервера ну и заходим. 8)
     
  4. Sam Jack

    Sam Jack Капитан-Узурпатор
    Команда форума Созидатель

    Регистрация:
    5 май 2015
    Сообщения:
    13.755
    Симпатии:
    4.749
    ОПТИМИЗАЦИЯ ВЕБ СЕРВЕРА: ИСПОЛЬЗУЕМ ЗЖАТИЕ КОНТЕНТА GZIP

    В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

    Nginx

    Nginx – сервер легкий; он запускает указанное число процессов (обычно число процессов = числу ядер), и каждый процесс в цикле принимает новые соединения, обрабатывает текущие. Такая модель позволяет с низкими затратами ресурсов обслуживать большое количество клиентов. Однако, при такой модели, нельзя выполнять длительные операции при обработке запроса (например mod_php), т.к. это по сути повесит сервер. При каждом цикле внутри процесса по сути выполняются две операции: считать блок данных откуда-то, записать куда-то. Откуда-то и куда-то – это соединение с клиентом, соединение с другим веб-сервером или FastCGI-процессом, файловая система, буфер в памяти. Модель работы настраивается двумя основными параметрами:
    worker_processes – число запускаемых процессов. Обычно устанавливают равным числу ядер процессора.
    worker_connections – максимальное число соединений, обрабатываемых одним процессом. Напрямую зависит от максимального числа открытых файловых дескрипторов в системе (1024 по умолчанию в Linux).

    Apache

    Apache – сервер тяжелый (следует заметить, что при желании его можно достаточно облегчить, однако это не изменит его архитектуры); он имеет две основных модели работы – prefork и worker.
    При использовании модели prefork Apache создает новый процесс для обработки каждого запроса, и этот процесс выполняет всю работу: принимает запрос, генерирует контент, отдает пользователю. Настраивается эта модель следующими параметрами:

    StartServers – задает число запускаемых процессов при старте веб-сервера.
    MinSpareServers – минимальное число висящих без дела процессов. Нужно это для того, чтобы при поступлении запроса быстрее начать его обрабатывать. Веб-сервер будет запускать дополнительные процессы, чтобы их было указанное количество.
    MaxSpareServers – максимальное число висящих без дела процессов. Это нужно, чтобы не занимать лишнюю память. Веб-сервер будет убивать лишние процессы.
    MaxClients – максимальное число параллельно обслуживаемых клиентов. Веб-сервер не запустит более указанного количества процессов.
    MaxRequestsPerChild – максимальное число запросов, которые обработает процесс, после чего веб-сервер убьет его. Опять же, для экономии памяти, т.к. память в процессах будет постепенно «утекать».


    Эта модель была единственной, которую поддерживал Apache 1.3. Она стабильная, не требует от системы многопоточности, но потребляет много ресурсов и немного проигрывает по скорости модели worker.
    При использовании модели worker Apache создает несколько процессов, по несколько потоков в каждом. При этом каждый запрос полностью обрабатывается в отдельном потоке. Чуть менее стабильна, чем prefork, т.к. крах потока может привести к краху всего процесса, но работает немного быстрее, потребляя меньше ресурсов. Настраивается эта модель следующими параметрами:

    StartServers – задает число запускаемых процессов при старте веб-сервера.
    MinSpareThreads – минимальное число потоков, висящих без дела, в каждом процессе.
    MaxSpareThreads – максимальное число потоков, висящих без дела, в каждом процессе.
    ThreadsPerChild – задает число потоков, запускаемых каждым процессом при старте процесса.
    MaxClients – максимальное число параллельно обслуживаемых клиентов. В данном случае задает общее число потоков во всех процессах.
    MaxRequestsPerChild – максимальное число запросов, которые обработает процесс, после чего веб-сервер убьет его.


    Фронтэнд-бэкэнд

    Основная проблема Apache – на каждый запрос выделен отдельный процесс (как минимум – поток), который к тому же увешан различными модулями и потребляет немало ресурсов. Вдобавок, этот процесс будет висеть в памяти до тех пор, пока не отдаст весь контент клиенту. Если у клиента узкий канал, а контент достаточно объемный, то это может занять длительное время. Например, сервер сгенерирует контент за 0,1 сек, а отдавать клиенту его будет 10 сек, все это время занимая системные ресурсы.
    Для решения этой проблемы используется архитектура фронтэнд-бэкэнд. Суть ее в том, что запрос клиента приходит на легкий сервер, с архитектурой типа Nginx (фронтэнд), который перенаправляет (проксирует) запрос на тяжелый сервер (бэкэнд). Бэкэнд формирует контент, очень быстро его отдает фронтэнду и освобождает системные ресурсы. Фронтэнд кладет результат работы бэкэнда в свой буфер и может долго и упорно отдавать его (результат) клиенту, потребляя при этом намного меньше ресурсов, чем бэкэнд. Дополнительно фронтэнд может самостоятельно обрабатывать запросы статических файлов (css, js, картинки и т.д.), управлять доступом, проверять авторизацию и т.д.

    Настройка связки Nginx (фронтэнд) + Apache (бэкэнд)

    Предполагается, что Nginx и Apache у вас уже установлены. Необходимо настроить сервера так, чтобы они слушали разные порты. При этом, если оба сервера установлены на одной машине, бэкэнд лучше вешать только на loopback-интерфейс (127.0.0.1). В Nginx это настраивается директивой listen:
    listen 80;


    В Apache это настраивается директивой Listen:
    Listen 127.0.0.1:81


    Далее нужно указать Nginx проксировать запросы на бэкэнд. Это делается директивой proxy_pass 127.0.0.1:81;. Это вся минимальная конфигурация. Однако выше мы говорили, что отдачу статических файлов лучше тоже поручить Nginx. Допустим, что у нас типичный сайт на PHP. Тогда нам нужно проксировать на Apache только запросы к .php файлам, обрабатывая все остальное на Nginx (если ваш сайт использует mod_rewrite, то реврайты тоже можно делать на Nginx, а .htaccess файлы просто выкинуть). Также необходимо учесть, что запрос клиента приходит на Nginx, а запрос к Apache делает уже Nginx, поэтому HTTP-заголовка Host не будет, а адрес клиента (REMOTE_ADDR) Apache определит как 127.0.0.1. Заголовок Host подставить несложно, а вот REMOTE_ADDR Apache определяет сам. Решается эта проблема при помощи mod_rpaf для Apache. Работает он следующим образом: Nginx знает IP клиента и добавляет некий HTTP-заголовок (например X-Real-IP), в который прописывает этот IP. mod_rpaf получает этот заголовок и прописывает его содержимое в переменную REMOTE_ADDR Apache. Таким образом, php-скрипты, выполняемые Apache будут видеть реальный IP клиента.
    Теперь конфигурация усложнится. Сначала позаботьтесь, чтобы и в Nginx, и в Apache существовал один и тот же виртуальный хост, с одинаковым корнем. Пример для Nginx:
    server {
    listen 80;
    server_name skripter.info;
    root /var/www/skripter.info/;
    }

    Пример для Apache:
    <VirtualHost 127.0.0.1:81>
    DocumentRoot "/var/www/skripter.info/"
    ServerName skripter.info
    </VirtualHost>

    Теперь задаем настройки для вышеописанной схемы:
    Nginx:
    server {
    listen 80;
    server_name skripter.info;
    location / {
    root /var/www/skripter.info/;
    index index.php;
    }
    location ~ \.php($|\/) {
    proxy_pass http://127.0.0.1:81;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    }
    }
    Apache:
    # настройки mod_rpaf
    RPAFenable On
    RPAFproxy_ips 127.0.0.1
    RPAFheader X-Real-IP

    <VirtualHost 127.0.0.1:81>
    DocumentRoot "/var/www/skripter.info/"
    ServerName skripter.info
    </VirtualHost>


    Регулярное выражение \.php($|\/) описывает две ситуации: запрос к *.php и запрос к *.php/foo/bar. Второй вариант необходим для работы многих CMS. При запросе skripter.info/ запрос будет переписан в example.com/index.php (т.к. мы определили index-файл) и также будет проксирован на Apache.

    Ускоряемся: gzip_static+yuicompressor

    Gzip в Web это хорошо. Текстовые файлы отлично сжимаются, трафик экономится, и контент быстрее доставляется пользователю. Nginx умеет сжимать на лету, так что тут проблем нет. Однако на сжатие файла тратится определенное время, в том числе процессорное. И тут на помощь приходит директива Nginx gzip_static. Суть ее работы в следующем: если при запросе файла Nginx находит файл с таким же именем и дополнительным расширением ".gz", например, style.css и style.css.gz, то вместо того, чтобы сжимать style.css, Nginx прочитает с диска уже сжатый style.css.gz и отдаст его под видом сжатого style.css.
    Настройки Nginx будут выглядеть так:
    http {
    ...
    gzip_static on;
    gzip on;
    gzip_comp_level 9;
    gzip_types application/x-javascript text/css;
    ...


    Прекрасно, мы один раз будем генерировать .gz файл, чтобы Nginx много раз его отдал. А дополнительно мы будем сжимать css и js при помощи YUI Compressor. Эта утилита максимально минимизирует css и js файлы, удаляя пробелы, сокращая наименования и т.д.
    А заставить все это сжиматься автоматически, да еще и обновляться автоматически можно при помощи cron и небольшого скрипта. Пропишите в cron для запуска раз в сутки следующую команду:
    /usr/bin/find /var/www -mmin 1500 -iname "*.js" -or -iname "*.css" | xargs -i -n 1 -P 2 packfile.sh


    в параметре -P 2 укажите число ядер вашего процессора, не забудьте прописать полный путь к packfile.sh и изменить /var/www на ваш веб-каталог.
    В файл packfile.sh пропишите:
    java -jar /var/www/gzip/yuicompressor-2.4.2.jar "$1" | gzip -c -9 > "$1.gz"
     
  5. Sam Jack

    Sam Jack Капитан-Узурпатор
    Команда форума Созидатель

    Регистрация:
    5 май 2015
    Сообщения:
    13.755
    Симпатии:
    4.749
    ТЮНИНГ NGINX

    Сегодня речь пойдет о небольшой оптимизации веб-сервера nginx. Задача — уменьшить время загрузки веб-странички у клиентов. Решение — небольшой тюнинг конфигов nginx.

    Разбираем конфиг nginx. По умолчанию находится в /usr/local/nginx/conf/nginx.conf или в /etc/nginx/nginx.conf В моем случае это первый вариант.

    Редактируем:

    nano /usr/local/nginx/conf/nginx.conf

    Видим конфиг:

    # Пользователь, от которого работает nginx
    user www-data www-data;
    # Кол-во процессов — ставится значение, равное кол-ву ядер в системе
    worker_processes 4;

    # Пишем логи
    error_log logs/error.log;
    error_log logs/error.log notice;
    error_log logs/error.log info;

    # Кол-во соединений
    events {
    worker_connections 2048;
    }

    http {
    # Подключаем mime
    include mime.types;
    default_type application/octet-stream;

    # Запись Access-логов. По желанию. Можно добавлять в вирт. хосты
    #access_log logs/access.log main;

    # Лучше включить — значительно повышает скорость отдачи контента.
    sendfile on;

    # Каждому свое. Для блога на wordpress хорошо подходит параметр, равный 15.
    keepalive_timeout 15;

    # Если мы используем проксирование, то параметры удобнее вывести в отдельный файл:
    include /etc/nginx/proxy.conf;

    # Выключаем версию сервера
    server_tokens off;

    # Подключаем файл с виртуальными хостами
    include /etc/nginx/sites-enabled/*;

    # Параметры сжатия gzip
    gzip on;
    gzip_buffers 4 8k;
    gzip_comp_level 7;
    gzip_proxied any;
    gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # Включаем кеширование заголовков
    expires max;

    # Позволяет передавать файл в полных пакетах
    tcp_nopush on;
    # Разрешает/запрещает tcp_nodelay при переходе в состояние keep_alive
    tcp_nodelay on;
    }

    Пока всё. Отредактируем proxy.conf

    nano /etc/nginx/proxy.conf


    # Переадресация прокси
    proxy_redirect off;
    # Передаем через прокси внешний IP клиента
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # Остальные параметры proxy
    client_max_body_size 10m;
    client_body_buffer_size 128k;
    proxy_connect_timeout 90;
    proxy_send_timeout 90;
    proxy_read_timeout 90;
    proxy_buffer_size 4k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;


    После этого перезапускаем Nginx.
     

Поделиться этой страницей

iHax Community
Рейтинг@Mail.ru Яндекс.Метрика мониторинг сайтов
Форум программного обеспечения/
Загрузка...