Уроки, извлеченные из отладки производительности приложений в облаке
Подъем и перенос миграции с помощью таких инструментов, как Cloudendure, - это самый быстрый способ миграции «локальных» систем в Google Cloud. После завершения миграции среду можно реорганизовать для использования собственных облачных возможностей.
Во время тестирования приложения после недавней автоматической миграции с использованием Cloudendure на GCP унаследованное веб-приложение начало демонстрировать значительный удар по производительности.
Загрузка веб-страницы perl заняла 40 секунд по сравнению с 5 секундами загрузки в «локальной системе». Система боковой нагрузки была очень минимальной.
Во время отладки на стороне клиентского браузера было обнаружено, что большую часть времени проходит зря !!
Это означает, что время загрузки, скорее всего, было потрачено на стороне сервера.
Команда pstree показала, что процессы chmod были созданы скриптом perl.
# pstree|grep chmod |-httpd-+-httpd---perl---chmodchmod пытается «chmod -R 755» на большом количестве файлов журнала. Процесс находится в состоянии uninturruptable_sleep.
# ps aux|grep chmodapache 17694 0.0 0.0 4088 588 ? D 11:09 0:00 chmod -R 755 log/*.log root 17722 0.0 0.0 103316 884 pts/0 S+ 11:09 0:00 grep chmod</code>Чтобы понять, что делает процесс, можно использовать sysrq. Мы использовали sysrq + t, чтобы вывести состояние потока всех процессов.
При проверке процесса chmod он выглядел так, как будто процесс ожидает вызовов атрибутов NFS.
Nov 27 11:14:45 test kernel: chmod D 0000000000000000 0 17909 17908 0x00000080Nov 27 11:14:45 test kernel: ffff880036c7fb48 0000000000000082 0000000000000000 ffffffffa01b98ceNov 27 11:14:45 test kernel: 0000000000000000 0000000000000286 00044e0b542040d0 ffff88003787e2b0Nov 27 11:14:45 test kernel: ffffffff81ed13c0 00000001483610e6 ffff880037c27068 ffff880036c7ffd8Nov 27 11:14:45 test kernel: Call Trace:Nov 27 11:14:45 test kernel: [<ffffffffa01b98ce>] ? xs_send_kvec+0x8e/0xa0 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffffa01be5b0>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffffa01be5f2>] rpc_wait_bit_killable+0x42/0xa0 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffff8154bc0f>] __wait_on_bit+0x5f/0x90Nov 27 11:14:45 test kernel: [<ffffffffa01b7ffa>] ? xprt_release_xprt+0x7a/0x80 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffffa01be5b0>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffff8154bcb8>] out_of_line_wait_on_bit+0x78/0x90Nov 27 11:14:45 test kernel: [<ffffffff810a69b0>] ? wake_bit_function+0x0/0x50Nov 27 11:14:45 test kernel: [<ffffffffa01b440c>] ? call_transmit+0x1ec/0x2c0 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffffa01beb35>] __rpc_execute+0xf5/0x350 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffff81045fbc>] ? kvm_clock_read+0x1c/0x20Nov 27 11:14:45 test kernel: [<ffffffff810a67b7>] ? bit_waitqueue+0x17/0xd0Nov 27 11:14:45 test kernel: [<ffffffffa01bedf1>] rpc_execute+0x61/0xa0 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffffa01b5475>] rpc_run_task+0x75/0x90 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffffa01b5592>] ? rpc_call_sync+0x42/0x70 [sunrpc]Nov 27 11:14:45 test kernel: [<ffffffffa0273b9c>] ? nfs3_rpc_wrapper.clone.0+0x6c/0xc0 [nfs]Nov 27 11:14:45 test kernel: [<ffffffffa0274f27>] ? nfs3_proc_getattr+0x47/0x90 [nfs]Nov 27 11:14:45 test kernel: [<ffffffffa0262293>] ? __nfs_revalidate_inode+0xe3/0x220 [nfs]Nov 27 11:14:45 test kernel: [<ffffffffa026312e>] ? nfs_getattr+0xde/0x210 [nfs]Nov 27 11:14:45 test kernel: [<ffffffff8119f9b1>] ? vfs_getattr+0x51/0x80Nov 27 11:14:45 test kernel: [<ffffffff81299e15>] ? _atomic_dec_and_lock+0x55/0x80Nov 27 11:14:45 test kernel: [<ffffffff8119fa44>] ? vfs_fstatat+0x64/0xa0Nov 27 11:14:45 test kernel: [<ffffffff8119fbab>] ? vfs_stat+0x1b/0x20Nov 27 11:14:45 test kernel: [<ffffffff8119fbd4>] ? sys_newstat+0x24/0x50Nov 27 11:14:45 test kernel: [<ffffffff810ee687>] ? audit_syscall_entry+0x1d7/0x200Nov 27 11:14:45 test kernel: [<ffffffff8100c6e5>] ? math_state_restore+0x45/0x60Nov 27 11:14:45 test kernel: [<ffffffff8154e68e>] ? do_device_not_available+0xe/0x10Nov 27 11:14:45 test kernel: [<ffffffff8100b0d2>] ? system_call_fastpath+0x16/0x1bNov 27 11:14:45 test kernel: Sched Debug Version: v0.09, 2.6.32-696.13.2.el6.x86_64 # Файлы журналов передаются с локального NAS-сервера.
Во время автоматической миграции сервер был перенесен на us-central1, поскольку это был самый дешевый регион. Сервер NAS находится в Европе и имеет большое время прохождения сигнала в обоих направлениях при пинге от экземпляра GCP:
# ping nas.test.comPING nas.test.com (192.168.1.50) 56(84) bytes of data.64 bytes from nas.test.com (192.168.1.50): icmp_seq=1 ttl=254 time=121 ms64 bytes from nas.test.com (192.168.1.50): icmp_seq=2 ttl=254 time=120 ms64 bytes from nas.test.com (192.168.1.50): icmp_seq=3 ttl=254 time=120 ms |
По сравнению с локальным сервером:
|
1
2
3
4
5
|
# ping nas01PING nas.test.com (192.168.1.50) 56(84) bytes of data.64 bytes from nas.test.com (192.168.1.50): icmp_seq=1 ttl=252 time=15.8 ms64 bytes from nas.test.com (192.168.1.50): icmp_seq=2 ttl=252 time=15.5 ms64 bytes from nas.test.com (192.168.1.50): icmp_seq=3 ttl=252 time=15.9 ms |
Повторное развертывание экземпляра на europe-west3 сократило время загрузки страницы с 40 до 5 секунд.
Мораль этой истории очевидна: держите ваши данные как можно ближе к экземпляру виртуальной машины.
Замечания:
* Всегда планируйте стратегию переноса данных перед перемещением виртуальных машин.
* Если возможно, перенесите данные в облако. Файловое хранилище можно использовать в этом сценарии без существенных изменений в приложении / системе.
* Переписать старые приложения в максимально возможной степени. Простым решением здесь может быть отделение chmod от веб-страницы. Например, используйте отдельный процесс или cron. Это еще больше сократит время загрузки страницы.