Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Здравствуйте!
Простейшие миграции 50 таблиц на WAMP (mysql 5.7, чистая база, сразу после drop) отрабатывают очень долго (несколько минут).
На LAMP те же самые миграции отрабатывают практически мгновенно.
В какую сторону тюнить mysql?
Не в сети
Не понимаю вопроса. По-моему, уже лет 15 как все согласились, что использовать Windows как веб-сервер для работы приложений на php/MySQL - извращение.
Винда - все-таки десктопная система. Чтоб человек работал за компом. В этом качестве - у Винды можно найти преимущества. Но сервер для работы php/MySQL... Да тот же ASP.NET глохнет даже не по причине собственно ASP.NET, а по причине того, что ты в винде или админ, или гуано. Ну и потому, что это одна большая дыра. Юзеру-то это скорее хорошо. Чем легче ему добираться до ресурсов своего компа - тем лучше 
В общем, забудь о винде как сервере для своего проЁкта.
Не в сети
Я поражен вашей мудрой проницательностью. Как Вы всё верно расписали, так дело и обстоит.
Серверы у нас - под linux. Винда используется строго как десктопная система. И так получилось, что на ней человек работает за компом.
В этом качестве у Винды находятся определенные преимущества для данного конкретного человека.
Вот вам use case - человек сидит в глухом лесу, после баньки работает за своим любимым клавиатурным планшетником с виндой десяточкой над любимым проектом. С интернетом, сами понимаете, небольшие перебои - лес, деревья, волки и лисы вокруг.
А миграции - тормозят. Так может, поможем человеку подкрутить мускул, чтобы он не жужжал дисками при выполнении DDL, вместо того чтобы в очередной раз, блистая бронзой, аки звезда на небосводе, расcказывать, как космические корабли бороздят просторы Большого театра?
Всегда радовали такие люди, которые вместо конкретного ответа на конкретный вопрос, начинают рассказывать, какая винда масдай.
Не в сети
- Слушайте, у меня же... у меня же ботинок пропал. Вы спрашивали - что-нибудь случилось? У меня же ботинок пропал.
- Сэр Генри, ваш башмак найдётся.
- Нет, я думал, может быть, интересно.
- Просто засунули куда-нибудь и всё.
- Нет, вы не подумайте, что мне жалко, джентльмены.
Просто я только вчера их купил на Стрэнде и даже ни разу не успел надеть. Выставил за дверь - и всё...
- Вы выставили за дверь... новые ботинки?
- Нет... Они были просто светло-коричневого цвета. Я не очень люблю этот цвет и поэтому оставил там записку, чтобы......их помазали чёрной ваксой. Ну, чёрные чтобы были.
- Но почему вы не купили чёрные ботинки?
Почему, сэр Генри?
- А что в этом странного? К чему вы клоните?
Что вы хотите этим сказать, доктор Ватсон?
Не в сети
В качестве костыля пришлось поднять Убунту на виртуальной машине и поселить Мускул туда.
Никакие камлания с глобальными переменными виндового Мускула (равно как и Машеньки), не помогли ускорить отработку миграций.
Не в сети
Мастер 
- вместо того чтобы в очередной раз, блистая бронзой, аки звезда на небосводе, расcказывать, как космические корабли бороздят просторы Большого театра?
Неистово плюсую. Зачётный ответ.
А по теме — в какой именно момент тормозят миграции? Миграция это же не просто один SQL-запрос, а куча разных действий. Сначала нужно выяснить, где тормозит, т.е. удалять из миграции команды, пока она не перестанет тормозить. Если тормозят любые миграции — как ведут себя обычные запросы к БД? Они тоже тормозят? Если да, возможно проблема с медленным DNS-ресолвером.
Какие симптомы? БД просто висит или нагружается диск/ЦП и пр.? Возможно там где-то создаётся временная таблица, их иногда можно отследить, найдя файлы с # в имени в папке с файлами БД (data).
Не в сети
Неистово плюсую. Зачётный ответ.
Вам осталось перейти на язык падонкафф. Чтоб защитить святое право завинчивать винты ножом, а не отверткой.
Не в сети
Мастер Не в сети
вы сами же начали. Как ответили - так и получили.
Я ответил,что нужно нужно подбирать технологии по назначению. А получил бакланство.
Это всё-таки разные вещи.
В общем, забудь о винде как сервере для своего проЁкта.
Да и вообще, с каких пор Windows не подходит для веб-разработки?
Перечитайте, для чего она не подходит. Как сервер. А если хочется именно на Винде работать, сочиняя свою нетленку - нужно человеку в его лес привезти системник, который уже не тянет офисную работу - и поднять на нём LAMP. Соединить их кабелем - и наслаждаться.
Но нет. Это как-то по-пиндосски, да? Будем растить кукурузу в Арктике, зимнюю олимпиаду проводить в субтропиках, воздевывать рис в безводном Крыму... А кто возразит - шутить про Большой театр. Смешно ведь. РЖУНИМАГУ
Не в сети
Перешел с винды на Linux только из-за предвзятого отношения заказчиков к винде.
За 14 лет работал на виндах, нескольких дистрибах Linux, Mac Os. Скажу так, что для разработки раньше видна была не очень удобна, но при грамотном подходе вообще разницы не чувствовалось. Сейчас же разницы вообще нет. Даже если нужна полная копия сервера со всем софтом - есть Vagrant/Homestead. Единственное, что нравится в Ubuntu по сравнению с Homestead на винде - это более высокая скорость работы. Если проект относительно простой и Homestead не используется, разницы вообще нет. Это мой опыт, возможно у кого-то был другой опыт с виндой.
И еще, у меня два года был сервер на Windows Server 2003/PHP/MySQL, ничего негативного за это время не произошло.
Изменено AlexeyMezenin (05.01.2017 12:24:42)
Не в сети
Это мой опыт, возможно у кого-то был другой опыт с виндой.
Всё не так плохо, когда Вы, так сказать, Artisan
То есть Вы один работаете с сервером и админ на нём. Конечно, нужен "грамотный подход", чтоб дыры Винды затыкать, ну и вот, как у лесного обитателя, что-то тормозит (уж не без этого, Винда всё-таки!) - но жить можно.
Но если команда разработчиков - тогда всё становится совсем плохо.
Не в сети
Мастер tmanager, вы бредите. Человек не говорил, что у него именно сервер на Windows. Наоборот, он написал, что на Linux всё работает, так что вероятно он знает о разнице между двумя ОС. Он спросил, почему яблоко кислое, а вы ответили, что ласточки нынче высоко летают.
- Конечно, нужен «грамотный подход», чтоб дыры Винды затыкать, ну и вот, как у лесного обитателя, что-то тормозит (уж не без этого, Винда всё-таки!) — но жить можно.
У вас какое-то очень оригинальное восприятие мира. Я постоянно работаю с людьми и это целый зоопарк систем — кто-то на Mac, кто-то на *nix, кто-то на Win7, а кто-то вообще на XP. Никаких трений из-за ОС, каждый сам выбирает, чем пользоваться. git, PHP, MySQL, Apache есть для любой из них. А если сказать кому-то «никто не использует XYZ, ибо так есть» — вас пошлют лесом. Потому что у каждой системы без исключения есть проблемы, но почему-то такие советчики о них забывают.
«Дыру Винды» даже комментировать не буду, это совершенно глупый стереотип на уровне домохозяек.
- И еще, у меня два года был сервер на Windows Server 2003/PHP/MySQL, ничего негативного за это время не произошло.
Даже больше, многие онлайн-казино используют Windows для своих серверов. Не лучший выбор, ИМХО, но учитывая уровень некоторых админов они бы на *nix в жизни ничего не подняли бы. Имеет право на жизнь.
Не в сети
Он спросил, почему яблоко кислое, а вы ответили, что ласточки нынче высоко летают.
Неправда. Я ответил, почему яблоко кислое: сорт такой. Неуважаемые Вами домохозяйки не станут спрашивать, как подсластить кислое яблоко. Но Вы ж не домохозяйка. Вы умнее, ага.
"Дыру Винды" даже комментировать не буду, это совершенно глупый стереотип на уровне домохозяек.
Домохозяйки, кстати, подметили, что в Винде php работает от имени пользователя System.
но учитывая уровень некоторых админов они бы на *nix в жизни ничего не подняли бы. Имеет право на жизнь.
А вот это уже ближе к телу.
Не в сети
Мастер 
слушайте, причём тут винда? да, есть определённые неудобства, но в целом пхп-стек работает на винде на ура. проработал под виндой с веб-разработкой три года (сейчас – перешёл на макось) и всё работало прекрасно. во-первых под виндой спокойно поднимается т.н. wamp и бОльшая часто кода просто работает (проблемы начинаются там где через exec стартует что-то специфичное), во-вторых есть virtualbox/vagrant/homestead – вот там начинаются тормоза из-за отвратительной производительности shared folders в virtualbox. тем не менее работать вполне можно. ну и наконец примерно с лета 2016 есть нативный докер для винды – он работает через hyper-v и с производительностью там всё прекрасно. к тому же не проблема запустить и такие вещи как постгрес или мемкэш или редис – всё есть в наличии.
а линукс на десктопе – это просто неудобно. с этим можно смириться если тачка чисто рабочая, но всё равно неудобно. на маке живётся поинтереснее, причём сейчас вполне реально недорого собрать производительный хакинтош, если финансы ограничены. при этом в наличии весь стандартный набор гнушного софта (слава homebrew), пхп-стек тоже работает совершенно стандартным способом (например через valet), докер прекрасно пашет – очень пригождается если приходится работать совместно с другими разработчиками на других ОС, или если нужно быстро поднять идентичное продакшену окружение со строго определёнными версиями пхп, мускула и пр.
собственно винда как по мне так вообще не проблема. да, она малость своенравна, но за последние лет 5 её неплохо обточили напильником и на современном железе она работает отлично и вполне юзабельна для веб-разработки. по опыту при работе с пхпштормом 8гиг памяти минимум, 16 – очень желательно. особенно если поднимать виртуалки. ссд прекрасны – убирают большое количество тормозов при использовании инструментария на js (gulp, webpack, npm).
а возвращаясь к вопросу топик-стартера о миграциях: я бы в первую очередь смотрел на my.cnf, из коробки (если мускул скачивался с mysql.com) ставится конфиг с очень неэффективными настройками. поставь innodb_buffer_pool_size от 2G или больше и рестартани его – может помочь.
Не в сети
поставь innodb_buffer_pool_size от 2G или больше и рестартани его – может помочь.
Стоял на 2Gb, поставил 4Gb - не помогло.
Пробовал так же:
innodb_flush_log_at_trx_commit=2
MariaDB 10.1 и 10.2 - точно такое же поведение.
Вводная:
Дропаем database, создаем, запускаем миграции.
Бодро пролетает
Migration table not found.
Migration table created successfully.
после чего начинает интенсивно сношать HDD в течении примерно 30-60 секунд (в зависимости от количества таблиц на проекте).
воспроизводится на разных ПК (от 4 до 16 Gb RAM).
Не в сети
Мастер Гм...
А по теме - в какой именно момент тормозят миграции? Миграция это же не просто один SQL-запрос, а куча разных действий. Сначала нужно выяснить, где тормозит, т.е. удалять из миграции команды, пока она не перестанет тормозить.
innodb_flush_log_at_trx_commit=2
Значение 2 как раз сильно замедлит транзакции. 1 - по умолчанию, 0 - самое быстрое (и опасное).
Не в сети
Значение 2 как раз сильно замедлит транзакции. 1 - по умолчанию, 0 - самое быстрое (и опасное).
Все пробовал.
Не в сети
}%Добавь в миграции логирование \Log::info(....); и выводи время запуска. По крайней мере будет понятно куда дальше копать. Опция seed используется? Или просто migrate?
Попробую завтра.
Воспроизводится как с --seed, так и отдельно от сидирования.
Не в сети
Добавил логирование в начало каждой миграции на одном из проектов.
Колонка Linux — результаты выполнения на Ubuntu внутри виртуальной машины VMware (2 секунды).
Колонка Win — результаты выполнения на Windows (24 секунды).
Код PHP в обоих случаях исполнялся на Windows (под Linux только MySQL).
logLinux Win 04:07 05:20 04:07 05:20 04:08 05:20 04:08 05:21 04:08 05:21 04:08 05:22 04:08 05:23 04:08 05:23 04:08 05:24 04:08 05:24 04:08 05:25 04:08 05:25 04:08 05:25 04:08 05:26 04:08 05:27 04:08 05:28 04:08 05:28 04:08 05:30 04:09 05:31 04:09 05:32 04:09 05:34 04:09 05:35 04:09 05:37 04:09 05:38 04:09 05:39 04:09 05:39 04:09 05:40 04:09 05:40 04:09 05:40 04:09 05:41 04:09 05:42 04:09 05:43 04:09 05:43 04:09 05:44 ============ 2с 24с
Изменено Yozheg (06.01.2017 11:16:51)
Не в сети
Мастер Не в сети
Похоже дело в настройке MySQL, т.к. выполнение просто растянуто во времени. Попробуй скопировать my.cnf с Ubuntu в Windows (с нужными правками, конечно).
Сравнивал show global variables diff'ом, применял все различия, научился затормаживать create table еще в 2 раза Ускорить, увы, так и не удалось.
Файлы с данными VM и MySQL под Windows на одном диске? Если разных, может быть причиной задержек (например, если под Windows на сетевом).
На одном, не на сети, конечно же. Хотя, подозреваю, что проблема может лежать именно в этой плоскости - винда может просто дольше файлы таблиц создавать. Выборки-то отрабатывают за одинаковое время.
PS: плюнул и работаю дальше с Percona в виртуалке
Изменено Yozheg (06.01.2017 18:11:33)
Не в сети
Мастер
- Сравнивал show global variables diff’ом, применял все различия, научился затормаживать create table еще в 2 раза
Ускорить, увы, так и не удалось.
Это даже интересно. На хосте БД работает в разы дольше, чем в ВМ при одинаковом конфиге? Активность диска может показывать, что БД часто сбрасывает память в swap (подкачку), но у ВМ должны быть те же проблемы, либо она должна падать…
Не в сети
Swap на хост-машине отключен совсем (т.к. 16 гиг еще занять надо суметь).
Эксперимент был бы чистым, если бы mysql хранила всю базу в 1 файле, как MSSQL (ВМ же пишет в 1 файл).
А так, похоже, все тормоза при create table именно из-за накладных расходов NTFS на создание файлов под хранение таблиц.
Надо попробовать положить хранилище mysql на RAM-диск
Не в сети
Мастер
- Эксперимент был бы чистым, если бы mysql хранила всю базу в 1 файле, как MSSQL (ВМ же пишет в 1 файл).
Ни за что не поверю в «накладные расходы NTFS», у тебя же не миллион файлов обновляется. Да и NTFS это обычная, нормальная ФС. Тем более если у тебя InnoDB, то она всё равно хранит всё в одном файле (либо двух-трёх) — едином tablespace.
- Надо попробовать положить хранилище mysql на RAM-диск
Да, интересно. Если вся загрузка идёт на диск, то миграции выполнятся моментально?
Не в сети
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)
Писарь