По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
JIT-компиляция – это метод повышения производительности интерпретируемых программ. JIT расшифровывается как Just-in-time. Во время выполнения программа может быть скомпилирована в машинный код для повышения ее производительности. Также этот метод известен как динамическая компиляция.
Динамическая компиляция имеет несколько преимуществ перед статической. При запуске приложений на JAVA или C# среда выполнения может профилировать приложение во время его исполнения. Это позволяет создавать более оптимизированный код. Если поведение приложения меняется во время его исполнения, то среда выполнения может перекомпилировать код.
Есть некоторые недостатки, заключающиеся в задержках при запуске или непроизводительных издержках при компиляции во время выполнения. Чтобы ограничить эти издержки, многие JIT-компиляторы компилируют только пути кода, которые часто используются.
Обзор
Традиционно существует два метода преобразования исходного кода в форму, которую можно запустить на платформе. Статистическая компиляция преобразует код в язык для конкретной платформы. Интерпретатор непосредственно выполняет исходный код.
JIT-компиляция пытается использовать преимущества обоих. В то время как выполняется интерпретируемая программа, JIT-компилятор определяет участки часто используемого кода и компилирует его в машинный код. В зависимости от компилятора это можно сделать для метода или меньшего участка кода.
Впервые динамическая компиляция была описана в статье о языке LISP Дж. Маккарти в 1960 году.
Компиляция на лету, JIT или динамическая компиляция – это компиляция, которая выполняется непосредственно во время исполнения программы, а не до этого. Что в этот момент происходит? Перевод в машинный код. Преимущества JIT-компиляции заключаются в том, что поскольку компиляция происходит во время выполнения, то JIT-компилятор имеет доступ к динамической информации времени выполнения, а это в свою очередь позволяет ему оптимизировать процесс (например, встраивать функции).
Что важно понимать, когда речь идет о JIT-компиляции? Она скомпилирует байт-код в инструкции машинного кода работающего компьютера. Это означает, что полученный машинный код оптимизирован для архитектуры процессора конкретного компьютера.
В качестве примеров JIT-компиляторов можно привести JVM (Java Virtual Machine - виртуальная машина Java) на Java и CLR (Common Language Runtime – общеязыковая исполняющая среда) на C#.
История
Изначально компилятор отвечал за преобразование языка высокого уровня (выше, чем ассемблер) в объектный код (машинные инструкции), который затем должен был быть связан (линкером) с исполняемой программой.
В какой-то момент эволюции языков компиляторы начали компилировать язык высокого уровня в псевдокод, который затем интерпретировался (интерпретатором) для запуска программы. Это исключило объектный код и исполняемые программы и позволило перенести эти языки на несколько операционных систем и аппаратных платформ. Одним из первых был Pascal (который скомпилирован в P-Code); более современными примерами являются Java и C#. Со временем термин P-Code был заменен на байт-код, поскольку большинство псевдоопераций имеют длину в один байт.
JIT-компилятор – это функция интерпретатора, которая вместо интерпретации байт-кода при каждом вызове компилирует байт-код в инструкции машинного кода работающей машины, а затем вызывает этот объектный код. В идеальном варианте эффективность выполнения объектного кода должна превзойти неэффективность перекомпиляции программы при каждом ее запуске.
Обычный сценарий
Исходный код полностью преобразуется в машинный код.
JIT-сценарий
Исходный код преобразуется в структуру на языке ассемблера, например, IL (промежуточный язык) для C#, ByteCode для Java.
Промежуточный код преобразуется в машинный только тогда, когда приложение нуждается в том, чтобы необходимые коды были преобразованы в машинный код.
JIT или не JIT
При JIT-компиляции не весь код преобразуется в машинный код. Для начала преобразуется только необходимая часть кода. Затем, если вызываемый метод или выполняемые функции находятся не в виде машинного кода, то они тоже будут преобразованы в машинный код. Это снижает нагрузку на ЦП. Поскольку машинный код будет генерироваться во время выполнения, то JIT-компилятор создаст машинный код, оптимизированный для запуска архитектуры ЦП машины.
Ниже приведены некоторые примеры JIT-компиляторов:
Java: JVM (Java Virtual Machine – виртуальная машина Java)
C#: CLR (Common Language Runtime – общеязыковая исполняющая среда)
Android: DVM (Dalvik Virtual Machine – виртуальная машина Dalvik) или ART (Android RunTime – среда выполнения Android-приложений) в новых версиях
Виртуальная машина Java (JVM) выполняет байт-код и ведет подсчет времени выполнения функции. Если это значение превышает предустановленный порог, то JIT-компилятор компилирует код в машинный код, который в дальнейшем может быть выполнен непосредственно процессором (в отличие от случая, когда javac компилирует код в байт-код, а затем интерпретатор интерпретирует этот байт-код построчно, переводя его в машинный код, и выполняет его).
Кроме того, при следующем вычислении функции тот же скомпилированный код выполняется снова, в отличие от обычной интерпретации, когда код повторно интерпретируется построчно. Это значительно ускоряет процесс выполнения программы.
В предыдущей части нашей серии OSPF мы рассмотрели варианты ручной фильтрации маршрутов. Теперь мы обсудим маршруты по умолчанию и сравним OSPFv2 с OSPFv3.
Предыдущие статьи:
Расширенные возможности OSPF: Области
OSPF: создание конкретных типов областей
Ручная фильтрация маршрутов OSPF
Маршрут по умолчанию (Default Routes)
Мы изучили с вами, что OSPF может автоматически генерировать маршрут по умолчанию, когда это необходимо. Это происходит с некоторыми специальными типами областей. Например, если вы настраиваете totally stubby area, требуется маршрут по умолчанию, и OSPF генерирует этот маршрут автоматически из ABR.
Чтобы повысить гибкость ваших проектов, маршруты по умолчанию, вводимые в нормальную область, могут быть созданы любым роутером OSPF. Для создания маршрута по умолчанию используется команда default-information originate.
Эта команда содержит два варианта:
Вы можете объявлять 0.0.0.0 в домен OSPF, при условии, что объявляемый роутер уже имеет маршрут по умолчанию.
Вы можете объявлять 0.0.0.0 независимо от того, имеет ли объявляемый роутер уже маршрут по умолчанию. Этот второй метод выполняется путем добавления ключевого слова always к default-information originate
Рисунок 1 - топология OSPF
Используя нашу простую топологию из рисунка 1 еще раз, давайте настроим ATL2 для введения маршрута по умолчанию в нормальную, не магистральную область 1.
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z .
ATL2 (config)#router ospf 1
ATL2 (config-router)#default-information originate always
ATL2 (config-router)#end
ATL2#
Обратите внимание, что в этом примере мы используем ключевое слово always, чтобы убедиться, что ATL2 генерирует маршрут по умолчанию независимо от того, есть ли у устройства уже маршрут по умолчанию в его таблице маршрутизации.
Вот проверка на ORL:
show ip route
Сравнение OSPFv2 и OSPFv3
Каким бы удивительным ни был OSPFv2, он не может маршрутизировать префиксы IPv6 для нас. Это работу выполняет OSPFv3. Хорошей новостью для вас является тот факт, что вы можете использовать почти все, что вы узнали о OSPFv2 при переходе на протокол OSPFv3. Полная перестройка протокола не проводилась, и было сохранено как можно больше функциональных возможностей и этапов настройки.
Как вы узнаете далее, OSPFv3 предлагает использование семейств адресов в конфигурации, что делает этот протокол подходящим для переноса префиксов IPv6 или даже префиксов IPv4 с соответствующим семейством адресов.
В конце этой статьи демонстрируется «стандартная» конфигурация OSPFv3, а также конфигурация семейства адресов.
Важно иметь представление о ключевых сходствах и различиях между v2 и v3 протоколов OSPF. Вот сходства, которые описаны ниже:
В OSPFv3 процесс маршрутизации не создается явно. Включение OSPFv3 на интерфейсе приведет к созданию процесса маршрутизации и связанной с ним конфигурации.
Идентификатор маршрутизатора по-прежнему является 32-разрядным значением в OSPFv3, и процесс выбора идентификатора маршрутизатора остается таким же.
OSPF автоматически предпочитает loopback интерфейс любому другому виду, и он выбирает самый высокий IP-адрес среди всех loopback интерфейсов.
Если никаких loopback интерфейсов нет, то выбирается самый высокий IP-адрес в устройстве.
Вот некоторые ключевые отличия:
Эта функция отличается от OSPF версии 2, в которой интерфейсы косвенно включены с помощью режима конфигурации устройства.
При использовании nonbroadcast multiaccess интерфейса в OSPFv3 необходимо вручную настроить устройство со списком соседей.
Соседние устройства идентифицируются по их идентификатору устройства.
В IPv6 можно настроить множество префиксов адресов на интерфейсе.
В OSPFv3 все префиксы адресов на интерфейсе включены по умолчанию.
Вы не можете выбрать определенные префиксы адресов для импорта в OSPFv3; либо импортируются все префиксы адресов в интерфейсе, либо никакие префиксы адресов в интерфейсе не импортируются.
В отличие от OSPF версии 2, несколько экземпляров OSPFv3 могут быть запущены на линии.
Традиционная (стандартная) настройка OSPFv3
Чтобы продемонстрировать (и попрактиковать) конфигурацию OSPFv3 часть настроек мы отбросили.
Вот конфигурация нашей магистральной области (область 0) и не магистральной области (область 1) с использованием «традиционного» подхода OSPFv3.
ATL# configuration terminal
Enter configuration commands, one per line . End with CNTL/Z .
ATL(config)#ipv6 unicast-routing
ATL(config)#interface fa0/0
ATL(config-if)#ipv6 address 2001:1212:1212::1/64
ATL(config-if)#ipv6 ospf 1 area 0
ATL(config-if)#interface loopback0
ATL(config-if)#ipv6 address 2001:1111:1111::1/64
ATL(config-if)#ipv6 ospf 1 area 0
ATL(config-if)#end
ATL#
Обратите внимание, насколько знакомым кажется этот подход к настройке, он аналогичен настройке OSPFv2. Обратите внимание также, что мы должны глобально включить возможность одноадресной маршрутизации IPv6 на устройстве. Это не является действием по умолчанию. Вы также должны понять, что это не требуется для запуска IPv6 на интерфейсах, это просто требование сделать маршрутизацию трафика IPv6 на роутере.
Вот конфигурация наших двух других устройств:
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z .
ATL2 (config)#ipv6 unicast-routing
ATL2 (config)#int fa0/0
ATL2 (config-if)#ipv6 address 2001:1212:1212::2/64
ATL2 (config-if)#ipv6 ospf 1 area 0
ATL2 (config-if)#
*Mar 28 09:23 :25 .563 : %0SPFv3-5-ADJCHG: Process 1, Nbr
192.168.20.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
ATL2 (config-if)#int fa1/0
ATL2 (config-if)#ipv6 address 2001:2323:2323::2/64
ATL2 (config-if)#ipv6 ospf 1 area 1
ATL2 (config-if)#end
ATL2#
ORL#conf t
Enter configuration commands, one per line . End with CNTL/Z .
ORL(config)#ipv6 unicast-routing
ORL(config)#int fa1/0
ORL(config-if)#ipvб address 2001:2323:2323::3/64
ORL(config-if)#ipvб ospf 1 area 1
ORL(config-if)#end
ORL#
Теперь настало время для проверки. Обратите внимание, что я выполню все это на устройстве ORL для краткости. Обратите внимание еще раз на все замечательные сходства с OSPFv2:
show ipv6 route
show ipv6 ospf neighbor
show ipv6 ospf database
Конфигурация Семейства Адресов OSPFv3
Давайте завершим эту статью изучением стиля конфигурации семейства адресов OSPFv3. Помните, что это позволит нам использовать этот единый протокол для передачи префиксов IPv4 и IPv6.
Вот пример подхода к конфигурации семейства адресов OSPFv3:
BOS (config)#ipv6 unicast-routing
BOS (config)#router ospfv3 1
BOS (config-router)#address-family ipv6 unicast
BOS (config-router-af)#area 1 range 2001:DB8:0:0::0/128
BOS (config-router-af)#end
BOS#conf t
BOS (config)#interface fa1/0
BOS (config-if)#ipv6 ospf 1 area 1
Важно то, что если вы уже знакомы с семействами адресов из другого протокола (например, BGP), то эта настройка покажется вам очень простой. Также учтите, что подход к настройке OSPFv3 на подинтерфейсах не меняется.
Повышение нагрузки на серверы Linux может быть хорошей идеей, если вы хотите увидеть, насколько хорошо они работают, когда они загружены. В этой статье мы рассмотрим некоторые инструменты, которые помогут вам нагрузить сервер и оценить результаты.
Для чего вам необходимо подвергать свою систему Linux нагрузке? Потому что иногда вам может потребоваться узнать, как система будет вести себя, когда она находится под большим давлением из-за большого количества запущенных процессов, интенсивного сетевого трафика, чрезмерного использования памяти и т. д. Этот вид тестирования позволяет убедиться, что система готова к использованию.
Если вам нужно спрогнозировать, сколько времени потребуется приложениям для ответа и какие процессы могут выйти из строя или работать медленно под большой нагрузкой, проведение стресс-тестирования заранее является очень хорошей идеей.
К счастью для тех, кому нужно знать, как система Linux отреагирует на нагрузку, есть несколько полезных методов, которые вы можете использовать, и есть инструменты, которые вы можете использовать, чтобы упростить этот процесс. В этой статье мы рассмотрим несколько вариантов.
Создаем циклы своими руками
Данный первый метод предполагает запуск некоторых циклов в командной строке и наблюдение за тем, как они влияют на систему. Этот метод нагружает ЦП, значительно увеличивая нагрузку. Результаты можно легко увидеть с помощью команды uptime или аналогичных команд.
В приведенной ниже примере мы начинаем четыре бесконечных цикла. Вы можете увеличить количество циклов, добавляя цифры или используя выражение bash, например {1..6} вместо «1 2 3 4».
for i in 1 2 3 4; do while : ; do : ; done & done
В примере выше, команда, запускает четыре бесконечных цикла в фоновом режиме.
$ for i in 1 2 3 4; do while : ; do : ; done & done
[1] 205012
[2] 205013
[3] 205014
[4] 205015
В этом случае были запущены задания 1-4. Отображаются как номера заданий, так и идентификаторы процессов.
Чтобы увидеть влияние на средние значения нагрузки, используйте команду, подобную показанной ниже. В этом случае команда uptime запускается каждые 30 секунд:
$ while true; do uptime; sleep 30; done
Если вы собираетесь периодически запускать подобные тесты, вы можете поместить команду цикла в скрипт:
#!/bin/bash
while true
do
uptime
sleep 30
done
В выходных данных вы можете увидеть, как средние значения нагрузки увеличиваются, а затем снова начинают снижаться после завершения циклов.
Поскольку показанные нагрузки представляют собой средние значения за 1, 5 и 15 минут, потребуется некоторое время, чтобы значения вернулись к нормальным для системы значениям.
Чтобы остановить циклы, выполните команду kill, подобную приведенной ниже - при условии, что номера заданий равны 1-4, как было показано ранее в этой статье. Если вы не уверены, используйте команду jobs, чтобы проверить ID.
$ kill %1 %2 %3 %4
Специализированные инструменты для добавления нагрузки
Другой способ создать системный стресс - это использовать инструмент, специально созданный для того, чтобы нагружать систему за вас. Один из них называется stress и может воздействовать на систему разными способами. Стресс-инструмент - это генератор рабочей нагрузки, который обеспечивает стресс-тесты ЦП, памяти и I/O.
С параметром --cpu команда stress использует функцию извлечения квадратного корня, чтобы заставить ЦП усердно работать. Чем больше указано количество ЦП, тем быстрее будет нарастать нагрузка.
Второй сценарий watch-it (watch-it-2) может использоваться для оценки влияния на использование системной памяти. Обратите внимание, что он использует команду free, чтобы увидеть эффект стресса.
$ cat watch-it-2
#!/bin/bash
while true
do
free
sleep 30
done
Начало и наблюдение за стрессом:
$ stress --cpu 2
Чем больше ЦП указано в командной строке, тем быстрее будет нарастать нагрузка.
Команда stress также может вызвать нагрузку на систему, добавив I/O и загрузку памяти с помощью параметров --io (input/output) и --vm (memory).
В следующем примере выполняется команда для добавления нагрузки на память, а затем запускается сценарий watch-it-2:
$ stress --vm 2
Другой вариант для стресса - использовать параметр --io, чтобы добавить в систему действия по вводу/выводу. В этом случае вы должны использовать такую команду:
$ stress --io 4
После чего вы можете наблюдать за стрессовым I/O с помощью iotop. Обратите внимание, что iotop требует привилегий root.
До
После
stress - это лишь один из множества инструментов для добавления нагрузки в систему.