Введение
Производительность вашей сети может оказывать существенное влияние на общую производительность и надежность всей вашей ИТ-инфраструктуры. Если различные приложения и сервисы долго ожидают получения данных из сети или ваши клиенты не сразу могут установить соединение или получить нужную им информацию, то необходимо устранить такие проблемы.
Проблемы производительности также могут повлиять на надежность ваших приложений и оборудования. Они могут быть вызваны ошибками работы сети, а иногда даже сами могут являться причиной таких ошибок. Чтобы выяснить причины проблемы сети, сначала нужно понять природу этой проблемы. Обычно проблема связана либо с задержкой передачи данных (латентностью), либо с пропускной способностью сети.
Зачастую проблемы производительности работы сети обусловлены аппаратными ресурсами, когда скорость работы приложения ограничивается параметрами сетевого оборудования. Проблемы производительности также обычно связаны с определенным протоколом или системой, например NFS, или доступом через Web. С помощью средств операционной системы можно идентифицировать источник проблемы, чтобы далее предпринять соответствующие действия.
В этой статье рассматриваются следующие этапы идентификации проблем производительности.
- Определение базового уровня производительности
- Определение источника проблемы
- Получение статистики
- Идентификация узкого места
Характеристики работы сети
Чтобы понимать и диагностировать проблемы производительности, в первую очередь нужно определить базовый уровень производительности сети. Для начала давайте познакомимся с двумя ключевыми характеристиками, используемыми при определении производительности сети: латентность (задержка передачи данных) и пропускная способность сети.
Латентность сети
Латентность сети – это время между посылкой запроса и фактическим получением пакета удаленной стороной. Латентность служит метрикой производительности сети. Увеличение латентности является хорошим индикатором того, что сеть забита трафиком, т.е. количество передаваемых пакетов превышает мощность сетевого оборудования либо отправителю данных приходится делать паузу перед отправкой пакетов.
Также латентность сети может расти при усложнении структуры сети и количества машин и маршрутизаторов, через которые должны проходить пакеты. Длина кабеля между принимающим и передающим пакеты компьютерами также может влиять на задержку. На больших расстояниях традиционный медный кабель всегда работает медленнее оптоволоконного.
Следует различать латентность сети и латентность приложения. Латентность сети связана исключительно с передачей пакетов по сети, в то время как латентность приложения обозначает время между получением приложением запроса и ответом на него.
Пропускная способность сети
Пропускная способность – это количество пакетов, которые могут быть переданы по сети за определенный промежуток времени. Пропускная способность влияет на то, как много данных может быть передано. Она ограничивает либо скорость передачи данных на одну машину практическим максимумом, поддерживаемым сетевым соединением, либо среднюю скорость передачи данных при наличии множества одновременных соединений.
Теоретически пропускная способность никогда не должна меняться, если вы не меняете сетевой интерфейс и оборудование. Главным параметром, определяющим пропускную способность сети, является количество компьютеров, использующих сеть в данный момент времени.
Например, интерфейс Ethernet с пропускной способностью 1 Гбит/с может передавать 1 Гбит данных на один подключенный к сети компьютер, или по 100 Мбит одновременно на 10 компьютеров, или по 10 Мбит на 100 компьютеров. Разумеется, на практике редко возникают ситуации, когда требуется максимальная пропускная способность сети. На сервер приходит много сотен маленьких запросов с множества различных компьютеров, поэтому поддерживаемая сервером пропускная способность может быть существенно больше суммарной пропускной способности клиентов.
Получение статистики работы сети
Чтобы судить о наличии проблем в работе сети, необходимо знать ее базовую производительность, относительно которой можно строить свои предположения. Для этого необходимо определить значение таких параметров, как латентность и пропускная способность, а также выполнить всевозможные тесты сетевой инфраструктуры, чтобы получить представление о производительности и отслеживать ее изменение с течением времени.
Тестирование на определение базовой производительности сети следует проводить в контролируемых условиях. В идеале тесты следует выполнить как в изоляции (когда нет другого сетевого трафика), так и при типичной загрузке сети. Это даст вам две базовые оценки.
- В изолированных условиях следует определить производительность работы сервера с одним или несколькими клиентами при отсутствии другого сетевого трафика. Для обеспечения изоляции нужно либо выключить остальные сетевые сервисы, либо, в идеале, поместить сервер и клиент в изолированное сетевое окружение, идентичное вашему обычному сетевому окружению, но полностью от него изолированное.
- Для отслеживания производительности сети в стандартных условиях следует выключить в сети трафик, который создают приложения (такой, как трафик электронной почты, работы с файлами или Web), подключить к ней тестируемые клиент и сервер и проверить их работу.
Для фактического процесса тестирования можно использовать несколько стандартных инструментов и тестов, позволяющих определить характеристики сети.
Измерение латентности
Программа ping хорошо известна всем сетевым администраторам как простой инструмент проверки доступности и латентности сетевого устройства. Ping посылает устройству ICMP-пакеты и может работать с большинством машин, как с клиентами, так и с серверами, если они сконфигурированы так, чтобы отвечать на ICMP-запросы. Фактически ping посылает устройству эхо-пакет и ожидает, что устройство пришлет ему содержимое этого пакета обратно.
Во время работы ping может отслеживать время, которое проходит между посылкой пакета и получением ответа, и поэтому он является эффективным инструментом измерения времени отклика удаленной системы. В простейшем случае можно посылать на машину эхо-запросы и получать время ответа на них (листинг 1).
Листинг 1. Использование ping для определения латентности
$ ping example PING example.example.pri (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.169 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.167 ms ^C --- example.example.pri ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.167/0.168/0.169/0.001 ms
Чтобы остановить процесс ping используйте сочетание клавиш
Control-C.
В Solaris и AIX® для посылки нескольких эхо-пакетов и получения информации о времени их передачи нужно использовать параметр
-s.
Для получения средней базовой задержки можно с помощью параметра
-c
(в Linux®)
указать количество пакетов. В Solaris/AIX для этого необходимо указать размер пакета (по умолчанию 56 байт) и количество пакетов, которые следует послать, чтобы вам не приходилось вручную завершать процесс. В дальнейшем это можно использовать для автоматического извлечения информации о времени задержки (листинг 2).
Листинг 2. Задаем размер пакета при использовании ping в Solaris/AIX
$ ping -s example 56 10 PING example: 56 data bytes 64 bytes from example.example.pri (192.168.0.2): icmp_seq=0. time=0.143 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=1. time=0.163 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=2. time=0.146 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=3. time=0.134 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=4. time=0.151 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=5. time=0.107 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=6. time=0.142 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=7. time=0.136 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=8. time=0.143 ms 64 bytes from example.example.pri (192.168.0.2): icmp_seq=9. time=0.103 ms ----example PING Statistics---- 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 0.103/0.137/0.163/0.019
Пример, приведенный в листинге 2, выполнялся в период отсутствия активности в сети. Если бы проверяемая машина (или сама сеть) были заняты во время теста, то время отклика могло оказаться значительно больше. Инструмент ping сам по себе не всегда позволяет обнаружить отклонение от нормы, но иногда его применение помогает быстро понять, есть ли какая-либо проблема, которую нужно проанализировать.
Поскольку ping можно отключать, перед его использованием (для получения времени задержки), необходимо убедиться в том, что машина доступна.
В идеале следует отслеживать время отклика между машинами на протяжении некоторого времени или даже непрерывно, чтобы можно было наблюдать за средним временем ответа, а потом уже решать, с чего начинать работу над проблемой.
Использование sprayd
Демон sprayd и инструмент spray посылают большой поток пакетов на указанную машину и определяют, на какое количество этих пакетов был получен ответ. Не стоит полагаться на его данные как на надежный показатель производительности сети, потому что в своей работе он использует транспортный механизм без установления соединения. Данные, посылаемые без установления соединения, не могут быть гарантированно доставлены по своему назначению, поэтому пропущенные пакеты могут присутствовать в любом случае.
С учетом этого spray можно использовать, чтобы определить, загружена ли сеть большим объемом трафика, так как утеря пакетов, посланных без установления соединения (UDP) может означать, что сеть (или машина) слишком заняты.
Функция Spray есть в Solaris, AIX и некоторых других вариантах UNIX. Для использования spray может быть потребуется включить его демон (обычно с помощь inetd). Когда демон sprayd запущен, можно выполнить spray, указав ему имя машины (листинг 3):
Листинг 3. Использование spray
$ spray tiger
sending 1162 packets of length 86 to tiger ...
101 packets (8.692%) dropped by tiger
70 packets/sec, 6078 bytes/secКак мы уже упоминали, не следует рассматривать spray как надежный инструмент, однако большое количество пропущенных пакетов может быть ценным показателем.
Использование простых тестов передачи данных через сеть
Наилучшим методом определения пропускной способности сети является вычисление фактической скорости передачи данных на машину (или от нее). Имеется множество различных инструментов, которые можно использовать для тестирования разных приложений и протоколов, но обычно самый простой способ является и самым эффективным.
Например, определить пропускную способность сети при передаче файлов с помощью NFS можно с помощью следующего простого теста. Создадим с помощью mkfile большой файл (например, размером 2 ГБ: $ mkfile 2g 2gbfile) и затем замерим, сколько времени занимает его передача по сети на другую машину (листинг 4).
Листинг 4. Замеряем время передачи файла по сети на другую машину
$ time cp /nfs/mysql-live/transient/2gbfile . real 3m45.648s user 0m0.010s sys 0m9.840s
Следует выполнить этот тест несколько раз и вычислить среднее время передачи файла, чтобы получить представление о стандартной производительности.
Можно автоматизировать процесс копирования и замера времени с помощью сценария Perl, подобного тому, который показан в листинге 5.
Листинг 5. Автоматизируем копирование и замер времени с помощью сценария Perl
#!/usr/bin/perl
use Benchmark;
use File::Copy;
use Data::Dumper;
my $file = shift or die "Need a file to copy from\n";
my $srcdir = shift or die "Need a source directory to copy from\n";
my $count = shift || 10;
my $t = timeit($count,sub {copy(sprintf("%s/%s",$srcdir,$file),$file)});
printf("Time is %.2fs\n",($t->[0]/$count));Чтобы выполнить сценарий, нужно передать в него адрес директории с исходным файлом и имя исходного файла, а также необязательный параметр количества операций копирования, которые необходимо сделать. Пример выполнения сценария показан в листинге 6:
Листинг 6. Выполняем сценарий Perl
$ ./timexfer.pl 2gbfile /nfs/mysql-live/transient 20 Time is 28.45s
Подобный тест можно использовать как для начального определения производительности, так и в дальнейшем, во время работы для проверки скорости передачи данных.
Диагностика проблемы
Обычно идентификацией сетевых проблем приходится заниматься только при возникновении ошибки в использующем сеть приложении. Столкнувшись с проблемой, важно убедиться, что она связана именно с сетью, а не с чем-либо другим.
Сначала следует попробовать «достучаться» до машины с помощью ping. Если машина не отвечает на запросы ping, и другие способы связи через сеть также не работают, то в первую очередь нужно проверить кабели и убедиться в физическом наличии сетевого соединения.
Если машина отвечает на ping, но время отклика увеличилось, тогда необходимо определить, в чем причина проблемы. Увеличение времени отклика в редких случаях может быть связано с загруженностью машины, но чаще оно вызвано проблемами сети.
При большом времени отклика ping, полученном от одной машины, следует выполнить ping какой-нибудь другой машины сети, в идеале находящейся на другом коммутаторе. Это позволит понять, с чем связана эта проблема: с сетью или конкретной машиной.
Проверяем статистику работы сети
Если время отклика ping больше, чем вы ожидали, то следует собрать некоторую базовую статистику работы используемого вами сетевого интерфейса чтобы понять, связана ли проблема с сетевым интерфейсом или определенным протоколом.
В Linux получить некоторую базовую статистическую информацию о работе сети можно с помощью инструмента ifconfig (листинг 7).
Листинг 7. Получаем базовую статистическую информацию о сети с помощью ifconfig
$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:1a:ee:01:01:c0
inet addr:192.168.0.2 Bcast:192.168.3.255 Mask:255.255.252.0
inet6 addr: fe80::21a:eeff:fe01:1c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7916836 errors:0 dropped:78489 overruns:0 frame:0
TX packets:6285476 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11675092739 (10.8 GiB) TX bytes:581702020 (554.7 MiB)
Interrupt:16 Base address:0x2000Для нас важными являются строки, начинающиеся с RX и TX, в которых показана информация о посланных и полученных пакетах. Значение packets (пакеты) отображает количество переданных пакетов. Показатели errors (ошибки), dropped (потерянные пакеты) и overruns (переполнения) говорят о том, как много пакетов сигнализирует об определенной ошибке. Если количество потерянных пакетов велико по отношению к количеству посланных пакетов, то это может говорить о загруженности сети.
Также на любой платформе можно получить расширенную статистическую информацию с помощью программы netstat. В Linux этот инструмент предоставляет подробную статистику работы основных протоколов, например информацию о передаче TCP-IP и UDP пакетов. Кроме того, эта информация содержит и некоторую базовую статистику (листинг 8).
Листинг 8. Использование netstat
$ netstat -s
Ip:
8437387 total packets received
1 with invalid addresses
0 forwarded
0 incoming packets discarded
8437383 incoming packets delivered
6820934 requests sent out
6 reassemblies required
3 packets reassembled ok
Icmp:
502 ICMP messages received
3 input ICMP message failed.
ICMP input histogram:
destination unreachable: 410
echo requests: 82
echo replies: 10
1406 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 1313
echo request: 11
echo replies: 82
IcmpMsg:
InType0: 10
InType3: 410
InType8: 82
OutType0: 82
OutType3: 1313
OutType8: 11
Tcp:
8361 active connections openings
6846 passive connection openings
1 failed connection attempts
164 connection resets received
33 connections established
8305361 segments received
6688553 segments send out
640 segments retransmitted
0 bad segments received.
676 resets sent
Udp:
126083 packets received
1294 packets to unknown port received.
0 packet receive errors
130335 packets sent
UdpLite:
TcpExt:
5 packets pruned from receive queue because of socket buffer overrun
6792 TCP sockets finished time wait in fast timer
5681 delayed acks sent
Quick ack mode was activated 11637 times
150861 packets directly queued to recvmsg prequeue.
74333 bytes directly in process context from backlog
9141882 bytes directly received in process context from prequeue
3608274 packet headers predicted
42627 packets header predicted and directly queued to user
77132 acknowledgments not containing data payload received
374105 predicted acknowledgments
2 times recovered from packet loss by selective acknowledgements
77 congestion windows recovered without slow start after partial ack
1 TCP data loss events
17 timeouts after SACK recovery
2 fast retransmits
8 retransmits in slow start
236 other TCP timeouts
1453 packets collapsed in receive queue due to low socket buffer
11634 DSACKs sent for old packets
2 DSACKs sent for out of order packets
2 DSACKs received
77 connections reset due to unexpected data
50 connections aborted due to timeout
TCPDSACKIgnoredNoUndo: 1
TCPSackShiftFallback: 23
IpExt:
InBcastPkts: 4126В Solaris и других вариантах UNIX информация, предоставляемая netstat, различается в зависимости от варианта Unix. Например, в Solaris выдается детальная статистика по каждому протоколу и отдельная информация по соединениям IPv4 и IPv6 (листинг 9). В этом листинге результат работы netstat показан в сокращенном виде.
Листинг 9. Использование netstat в Solaris
$ netstat -s
RAWIP rawipInDatagrams = 440 rawipInErrors = 0
rawipInCksumErrs = 0 rawipOutDatagrams = 91
rawipOutErrors = 0
UDP udpInDatagrams = 15756 udpInErrors = 0
udpOutDatagrams = 16515 udpOutErrors = 0
TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400
tcpRtoMax = 60000 tcpMaxConn = -1
tcpActiveOpens = 1735 tcpPassiveOpens = 54
tcpAttemptFails = 2 tcpEstabResets = 35
tcpCurrEstab = 2 tcpOutSegs =13771839
tcpOutDataSegs =13975728 tcpOutDataBytes =1648876686
tcpRetransSegs = 90215 tcpRetransBytes =130340273
tcpOutAck =151539 tcpOutAckDelayed = 5570
tcpOutUrg = 0 tcpOutWinUpdate = 31
tcpOutWinProbe = 86 tcpOutControl = 3750
tcpOutRsts = 63 tcpOutFastRetrans = 6
tcpInSegs =7548720
tcpInAckSegs =2882026 tcpInAckBytes =1648874900
tcpInDupAck =4413016 tcpInAckUnsent = 0
tcpInInorderSegs =415007 tcpInInorderBytes =367832646
tcpInUnorderSegs = 7650 tcpInUnorderBytes =10389516
tcpInDupSegs = 222 tcpInDupBytes = 74649
tcpInPartDupSegs = 0 tcpInPartDupBytes = 0
tcpInPastWinSegs = 0 tcpInPastWinBytes = 0
tcpInWinProbe = 0 tcpInWinUpdate = 2
tcpInClosed = 33 tcpRttNoUpdate = 660
tcpRttUpdate =2880379 tcpTimRetrans = 2262
tcpTimRetransDrop = 10 tcpTimKeepalive = 630
tcpTimKeepaliveProbe= 314 tcpTimKeepaliveDrop = 17
tcpListenDrop = 0 tcpListenDropQ0 = 0
tcpHalfOpenDrop = 0 tcpOutSackRetrans = 69348
...Во всех случаях следует обращать внимание на высокий уровень пакетов с ошибками, повторно передаваемых или пропущенных пакетов. Все они является индикаторами того, что сеть занята. Если количество ошибок чрезмерно велико по отношению к количеству отправленных или полученных пакетов, это может сигнализировать о сбое сетевого оборудования.
Проверяем статистику NFS
Работая над неисправностями, связанными с соединениями NFS, или проблемами большинства других сетевых приложений, в первую очередь следует проверить, не вызваны ли они проблемами на самой машине, например высокой загрузкой центрального процессора (которая, конечно же, влияет на скорость обработки запросов). Простая проверка с помощью uptime и ps может вам сказать, насколько сильно занята данная машина.
Также можно проверить статистику работы сервиса NFS. Команда nfsstat генерирует детальную статистику работы как серверной, так и клиентской части сервиса NFS. Например, в листинге 10 мы выводим детальную статистику работы серверной части протокола NFS v3 сервиса NFS, используя параметры -s (сервер) и -v (версия).
Листинг 10. Вызов команды nfsstat с параметрами
-s и -v
$ nfsstat -s -v3 Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 36118 0 0 0 0 410 0 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 75 0 0 0 0 0 0 Server NFSv3: calls badcalls 35847 0 Version 3: (35942 calls) null getattr setattr lookup access readlink 15 0% 190 0% 83 0% 3555 9% 21222 59% 0 0% read write create mkdir symlink mknod 9895 27% 300 0% 7 0% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 0 0% 0 0% 0 0% 0 0% 37 0% 20 0% fsstat fsinfo pathconf commit 521 1% 2 0% 1 0% 94 0% Server nfs_acl: Version 3: (0 calls) null getacl setacl getxattrdir 0 0% 0 0% 0 0% 0 0%
Большое значение показателя badcalls говорит о том, что на сервер посылаются неправильные запросы, что может сигнализировать о неправильной работе клиента, от которого приходят некорректные запросы из-за какой-либо программной проблемы или сбоев оборудования.
Время отклика ping в больших сетях
Итак, машина отвечает на ping, но тем не менее имеются проблемы производительности сети. В таком случае нужно определить, в каком именно месте вашей сети возникла проблема. В крупных сетях, разделенных маршрутизаторами на отдельные сегменты, можно использовать программу traceroute, чтобы определить, в какой именно точке маршрута между двумя машинами имеется проблема.
Программы traceroute и ping имеют общие корни, благодаря чему первая из них предоставляет время отклика каждого маршрутизатора, через который пакет проходит по пути к месту назначения. В больших сетях это может помочь изолировать проблему. Также эту информацию можно использовать для идентификации потенциальных проблем при отправке пакетов через Internet, когда используются различные маршрутизаторы для передачи пакетов между разными Интернет-провайдерами.
Например, в листинге 11 показан полученный с помощью traceroute маршрут передачи пакета между двумя офисами в Великобритании, использующими разные Интернет-провайдеры. В данном случае, ввиду ошибки, пакет не удается доставить до пункта назначения.
Листинг 11. Отслеживаем c помощью traceroute путь пакета между двумя офисами в Великобритании
$ traceroute gendarme.example.com traceroute to gendarme.example.com (82.70.138.102), 30 hops max, 40 byte packets 1 voyager.example.pri (192.168.1.1) 14.998 ms 95.530 ms 4.922 ms 2 dsl.vispa.net.uk (83.217.160.18) 32.251 ms 95.674 ms 30.742 ms 3 rt-gw1.tcm.vispa.net.uk (62.24.228.1) 49.178 ms 47.718 ms 123.261 ms 4 195.50.119.249 (195.50.119.249) 47.036 ms 50.440 ms 143.123 ms 5 ae-11-11.car1.Manchesteruk1.Level3.net (4.69.133.97) 92.398 ms 137.382 ms 52.780 ms 6 PACKET-EXCH.car1.Manchester1.Level3.net (195.16.169.90) 45.791 ms 140.165 ms 35.312 ms 7 spinoza-ae2-0.hq.zen.net.uk (62.3.80.54) 33.034 ms 39.442 ms 33.253 ms 8 galileo-fe-3-1-172.hq.zen.net.uk (62.3.80.174) 34.341 ms 33.684 ms 33.703 ms 9 * * * 10 * * * 11 * * * 12 * * *
В сетях небольшого размера, в которых, скорее всего, нет разделения сети с помощью маршрутизаторов, применение traceroute не принесет пользы. Как ping, так и traceroute, при определении проблемы полагаются на доступность машины в сети.
Теперь вы обладаете некоторыми знаниями и приемами, которые помогут вам решать проблемы производительности в сетях UNIX.
Заключение
Проблемы производительности сети UNIX довольно сложно идентифицировать с отдельного компьютера, особенно с учетом того, что обычно проблема распределена по всей сети. Тем не менее, обычно при помощи инструментов ping и/или traceroute можно сузить область поиска, получая информацию о производительности из разных точек сети. Определив некоторые точки входа, можно с помощью других сетевых инструментов получить более детальную информацию о работе протокола или приложения, вызывающего проблему. В этой статье мы рассмотрели некоторые простые методы получения информации о базовой производительности сети, а затем несколько инструментов, которые можно использовать для анализа проблемы.
Ресурсы
- UNIX network performance analysis (Мартин Браун, developerWorks, сентябрь 2009 г.) - оригинал статьи (EN).
- System Administration Toolkit: Network Scanning (Мартин Браун, developerWorks, декабрь 2007 г.): в этой статье можно даются советы по сканированию сети .
- В статье System Administration Toolkit: Standardizing your UNIX command-line tools (Мартин Браун, developerWorks, май 2006 г.) объясняется как использовать одни и те же команды на разных компьютерах .
- Обратите внимание на серию статей Даниэля Роббинса (Daniel Robbins) о программировании на bash: Bash by example, Part 1: Fundamental programming in the Bourne again shell (bash) (developerWorks, март 2000 г.), Bash by example, Part 2: More bash programming fundamentals (developerWorks, апрель 2000 г.) и Bash by example, Part 3: Exploring the ebuild system (developerWorks, май 2000 г.) (EN).
- В статье Making UNIX and Linux work together (Мартин Браун, developerWorks, апрель 2006 г.) представлено руководство по организации совместной работы дистрибутивов Linux и традиционного UNIX.
- При работе в разных операционных системах используются разные инструменты, а также справочник от IBM Solaris to Linux Migration: A Guide for System Administrators, который поможет вам в них разобраться (EN).
- В wiki-разделе AIX вы можете найти общее пространство для размещения технической информации о AIX (EN).
- Посетите электронный магазин технической литературы Safari, чтобы найти интересующую вас информацию по этой и другим темам.(EN)
- Следите за новостями в разделе технических мероприятий и Web-трансляций developerWorks (EN).
- Подкасты: будьте на одной волне с техническими экспертами IBM. (EN)
Комментарии
Bluemix
Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!
Библиотека документов
Более трех тысяч статей, обзоров, руководств и других полезных материалов.
