Тормозит openserver windows 10

• Поисковые системы
  • Google
  • Яндекс
  • Каталоги сайтов
  • Прочие поисковики
  • Агрегаторы и доски объявлений
• Практика оптимизации
  • Общие вопросы оптимизации
  • Частные вопросы — ранжирование, индексация, бан
  • Сервисы и программы для работы с SE
  • Любые вопросы от новичков по оптимизации
  • Ссылочные и пользовательские факторы
  • Поисковые технологии
  • Doorways & Cloaking
• Трафик для сайтов
  • Поисковая и контекстная реклама
  • Google Adwords
  • Яндекс.Директ
  • Тизерная и баннерная реклама
  • Общие вопросы рекламы
• Монетизация сайтов
  • Партнерские программы в Интернете
  • Контекстная реклама
  • Google AdSense
  • Рекламная Сеть Яндекса
  • Размещение тизерной и баннерной рекламы
  • Общие вопросы
• Сайтостроение
  • Веб-строительство
  • Статистика и аналитика
  • Доменные имена
  • Администрирование серверов
  • Хостинг
  • Безопасность
  • Usability и удержание посетителей
  • Копирайтинг
• Социальный Маркетинг
  • Вконтакте
  • YouTube
  • Facebook & Instagram
  • TikTok
  • Telegram
  • Общие вопросы
• Общение профессионалов
  • Семинары и конференции
  • eCommerce, интернет-магазины и электронная коммерция
  • Телефония и коммуникации для бизнеса
  • Деловые вопросы
  • Финансы
  • Cчет в Яндекс.Деньгах
  • Криптовалюты
  • Инвестиции
  • Экономика
  • Правовые вопросы
• Биржа и продажа
  • Финансовые объявления
  • Работа на постоянной основе
  • Сайты — покупка, продажа
  • Соцсети: страницы, группы, приложения
  • Сайты без доменов
  • Трафик, тизерная и баннерная реклама
  • Продажа, оценка, регистрация доменов
  • Ссылки — обмен, покупка, продажа
  • Программы и скрипты
  • Размещение статей
  • Инфопродукты
  • Прочие цифровые товары
• Работа и услуги для вебмастера
  • Оптимизация, продвижение и аудит
  • Ведение рекламных кампаний
  • Услуги в области SMM
  • Программирование
  • Администрирование серверов и сайтов
  • Прокси, ВПН, анонимайзеры, IP
  • Платное обучение, вебинары
  • Регистрация в каталогах
  • Копирайтинг, переводы
  • Дизайн
  • Usability: консультации и аудит
  • Изготовление сайтов
  • Наполнение сайтов
  • Прочие услуги
• Не про работу
  • О сайте и форуме
  • Самое разное
  • Курилка
  • Встречи и сходки
  • Железо и софт

Google Ads будет устанавливать first-party cookie через глобальный тег сайта и GTM

История интернета. И при чем здесь святой Исидор?

Есть скрипт наполнения базы данных который работает по 5-6 часов, что нереально долго.

99,9 его работы состоит в запросах вида

Что я пытался делать:

1. В настройках опенсервера сменил версию пхп на 7 — не заметил разницы

2. Отрубил антивирь и защитника виндовс — не заметил разницы

3. Вырубил поддержку IP6 — стало чуть быстрее

4. Создал виртуальный диск в памяти, дал ему 20 гигов и запустил опенсервер оттуда — стало чуть быстрее

5. заменил локалхост на 127.0.0.1 — стало чуть быстрее

идеи закончились. Все мои потуги дали +10-15% к скорости.

Я то думал из оперативы он начнет летать (до этого было на ссд) — но скрипт по прежнему работает часы.

Что еще можно предпринять?

Анализируйте каждый запрос.

Вообще скрипт какой-то «ущербный». В том смысле, что что-то он делает «непонятное» и неясно надо ли это делать вообще.

Ну и наличие индекса по id проверьте :), и что он влезает в память.

PS. Не исключено, что проще забрать все данные в память, модифицировать их и выгрузить обратно.

От задачи зависит.

Про «данные в память» очень хорошая идея.

Когда-то мне пришлось парсить большой объём данных.

Скрипт работал неспешно, но что самое убийственное, с каждой новой записью быстродействие уменьшалось.

Я примерно прикинул, и понял, что предстоит не меньше недели работы, с постоянной высокой нагрузкой на диск.

Решил всё установкой виртуального диска и перенесением всех данных на него.

4 часа с нагруженным процессором и спящим диском.

Мне не помог виртуальный диск — разницы с SSD я не увидел. Переношу щас скрипт на ВПС. Надеюсь с серверным процессором и линуксом будет быстрее

Форум

Начинает сильно тормозить.

Начинает сильно тормозить.

Слишком расплывчатое описание Ваш глюк ни кто не сможет повторить у себя. Надо точнее определить симптомы и локализацию проблем(ы).
Разделяй и властвуй (с).

Первое, что приходит на ум:
1. Средствами браузера определите какой именно компонент тормозит (а ну как вообще у браузера проблемы).
2. Поглядите статистику мемкеша (в волшебный момент внезапно кончаются мозги).
3. Если токма на свежем серваке перестаёт тормозить — может оно базу как-то жутко уродует.

Windows 7 x64 mem 6gb HDD 8TB core i3
HDD barracuda 1TB — диск не системный
Браузер Chrome 43, IE 10-11.FF,Opera

1. Браузер здесь абсолютно не причем проблема проявляется во всех браузерах которые у меня установлены.
Получение первого TCP пакета index.php 5 — 7 сек. (Waiting TTFB )

DATABASE — MyISAM
объем таблиц не превышает 70 кб
количество таблиц 12 шт
Среднее число полей по таблицам от 10 -40

Запрос идет по одному объекту т.е. ID + запросы PREV and NEXT объект
Дополнительных TEMPORARY,MEMORY таблиц не создаются.

Получается, основной кандидат на тормознутость — пых.
Надо его смотреть какой кусок тормозит.

И хорошо бы глянуть что за запросы там возникают к БД (хотя тачка отличная, а база не большая). Ну вдруг он там генерит крос-джойн с подзапросами.

ЗЫ. Смущает, что тормозить начинает с какого-то момента.

Пока заменил запись при подключении к базе с ‘localhost’ ->’127.0.0.1′ переустановил все летает, жду глюка.

Да на сборке 5,2,0 такого не было запросы к базе были те же, т.е. сайт и страница та же, морду страниц часто меняю.

OpenServer не запускается: решение популярных ошибок

Локальный веб-сервер OpenServer не всегда работает корректно, особенно когда речь идет о его первом запуске после установки на компьютер. Часто пользователи сталкиваются с различными проблемами, приводящими к отсутствию отклика при запуске программы.

Далее я расскажу, как быстро избавиться от распространенных трудностей при работе с данным инструментом.

Просмотр логов OpenServer

Начну с небольшого совета, который чаще всего помогает сразу же распознать причину неполадки и решить ее, приложив минимальное количество усилий. Однако уточню, что подойдет эта рекомендация только в том случае, если сам OpenServer запускается в Windows, но при этом старта локального веб-сервера не происходит.

На панели задач есть значок программы, по которому нужно кликнуть правой кнопкой мыши. После этого появится контекстное меню, в котором надо нажать на «‎Просмотр логов» . В новом окне ознакомьтесь с полученными сведениями и определите, из-за чего появилась рассматриваемая ошибка.

Запуск программы от имени администратора

Как бы банально это ни звучало, но часто запуск OpenServer от имени администратора решает все неполадки. Дело в том, что сам компонент тесно связан с сетью и файлами, отвечающими за соединение, поэтому и требует определенных привилегий при взаимодействии с ними. Если права доступа отсутствуют, соответственно, и запуска программы не произойдет.

Вам понадобится выйти из панели управления, найти файл программы в корневом каталоге, щелкнуть по нему правой кнопкой мыши и в контекстном меню выбрать пункт «‎Запуск от имени администратора» . Подождите несколько секунд и проверьте, появилась ли на экране какая-либо информация, свидетельствующая о начале работы локального веб-сервера.

Если этот метод оказался эффективным, но вы не хотите каждый раз запускать программу таким образом, выполните простую настройку. Для этого снова кликните по исполняемому файлу правой кнопкой мыши и перейдите в «‎Свойства» . Там найдите вкладку «‎Совместимость» и установите галочку возле пункта «Запускать эту программу от имени администратора‎» .

После применения настроек софт всегда будет стартовать с повышенными привилегиями, что позволит избавиться от проблем с запуском.

Редактирование файла hosts

Встроенный в операционную систему файл hosts выполняет важную роль, и часто пользователи задействуют его, если хотят ограничить доступ к конкретным сайтам. Иногда его блокировка средствами Windows становится причиной проблем с запуском OpenServer. Информация об этом появляется в логах при попытке перейти на веб-сервер, поэтому причину можно сразу же распознать.

Хочу дать два совета:

1. При использовании стороннего антивируса и брандмауэра настройте их так, чтобы OpenServer не попадал в список заблокированных программ. Стандартные средства можно отключить на время исключительно в качестве проверки.
2. Запустите командную строку от имени администратора и введите команду attrib -s -r -h -a C:\Windows\system32\drivers\etc\hosts , активировав соответствующие атрибуты для упомянутого файла hosts.

Невозможно подключиться к серверу

Если же OpenServer запускается нормально, но при этом соединения с сервером не происходит, советую ознакомиться с дальнейшими инструкциями.

Способ 1: Редактирование MySQL и phpMyAdmin

Этот способ подойдет тем пользователям, которые используют OpenServer в связке с MySQL и phpMyAdmin. Он заключается в небольшой настройке этих двух компонентов для обеспечения нормального соединения, если вдруг возникла такая ситуация, что веб-сервер не хочет запускаться.

Первоочередная задача – создание нового пользователя MySQL. Вводим:

Команда отвечает за создание нового пользователя и установку для него пароля.

Откройте конфигурационный файл phpMyAdmin, который находится в папке /etc/phpmyadmin/config.inc.php . Добавьте туда две строки:

Вместо user и pass подставьте имя созданного пользователя и его пароль для MySQL.

Способ 2: Проверка данных авторизации

Последняя рекомендация будет самой банальной – проверка данных авторизации при входе на веб-сервер. Это касается ситуаций, когда на экране появляется ошибка «Невозможно подключиться к серверу MySQL mysqli::real_connect(): (HY000/1045): Access denied for user ‘root’@’localhost’ (using password: NO)» . Вам необходимо указать стандартный пароль и логин mysql или root в обоих полях, после чего авторизация должна пройти успешно.

Это были самые распространенные способы решения проблем с запуском OpenServer.

LiveStreet CMS

Интересные расширения из каталога

Вопросы

Прямой эфир

sersar 5 апреля 2021, 18:22

Chiliec 23 марта 2021, 12:36

lifecom 27 февраля 2021, 03:26

iVee 16 февраля 2021, 13:07

Doom74 5 февраля 2021, 09:03

Doom74 5 февраля 2021, 08:57

Doom74 5 февраля 2021, 08:56

Doom74 5 февраля 2021, 08:55

sersar 28 января 2021, 17:48

cshome 1 января 2021, 07:16

Работа!

Блоги

• Блог разработки LiveStreet137.33
• Сайты на LiveStreet121.49
• Вопросы83.57
• Дополнительные модули и доработки для LiveStreet73.21
• Техническая документация LiveStreet68.62
• Tips & tricks60.64
• Биржа заказов на разработку и поддержку за деньги56.28
• Предложения и пожелания46.04
• Шаблоны для LiveStreet38.75
• Решения проблем28.89

Медленная загрузка на локальной машине

Здравствуйте! Наблюдаю странно долгую загрузку страниц на локальной машине. От 2 до 7(!) секунд. Две разных установки LS, обе нулевые (плагины только из коробки). Вот цифры:
denwer3: Livestreet 1.0.1, Apache 2.2.4, PHP 5.2.12, MySQL 5.1.40 (InnoDB)

OpenServer: Livestreet 1.0.3, Apache/2.2.25, PHP 5.3.27, MySQL 5.5.33 (InnoDB), Memcached 1.4.5

Поиском нашлось два решения. Первое. Переключение file/memory в конфиге изменений не дает. Отключение кеша тоже, вот цифры:

Второе. Надо заменить InnoDB на MyISAM. Удалил в БД на денвере все foreign keys вручную, так же перевел все на MyISAM.

Результаты остались ровно те же.

Подскажите, такие цифры нормальны? Или что я делаю не так? Спасибо!

42 комментария

неужели никто не отлаживает на локальных машинах и под виндой

Второе. Надо заменить InnoDB на MyISAM. Удалил в БД на денвере все foreign keys вручную, так же перевел все на MyISAM.

Отключал кеширование, и написал об этом в первом пункте (когда менял еще тип кеша). Не помогло. И вот только что еще раз перепроверил — то же самое.

Насчет InnoDB/MyISAM. Я просто попробовал варианты, которые нагуглил тут на сайте. Кому-то смена типа на myisam как раз помогла, хотя да, все говорят, что целостность-безопасность-итп.

Дело не в InnoDB, а в том как он настроен.

И будет вам счастье.

уже было, только в формате
Стали появляться цифры 1,6-2,1 вместо 2,1-2,6 но на некоторых страницах все равно вылетает и 4,6. Но 1,6 уже лучше (:

Вот весь конфиг innodb:

Стали появляться цифры 1,6-2,1 вместо 2,1-2,6 но на некоторых страницах все равно вылетает и 4,6. Но 1,6 уже лучше (:

Вы не очень поняли что произошло. У нормально настроенного LS база данных не является узким местом. Узкое место там Smatry. Поэтому тестировать это дело надо на топике с несколькми сотнями комментариев от кучи пользователей — вот там заметно что и как. Если у вас скажем такая страница генерируется 2 секунды, то база там будет занимать не больше 25% общего времени и даже если вы уберете базу в ноль — на общем времени генерации эффект не будет особо заметен.

как я уже писал, при прочих равных innodb_flush_log_at_trx_commit = 2 очень увеличивает скорость INSERT/UPDATE. где вы почувствуется эффект от этого? — там где они есть, а ничего другого нет. Например Ajax запроса на «+» или «-» заметки или топика, или добавление нового комментария — должны заработать намного быстрее.

Если у вас скажем такая страница генерируется 2 секунды, то база там будет занимать не больше 25% общего времени и даже если вы уберете базу в ноль — на общем времени генерации эффект не будет особо заметен.

Примерно понял. Но вот цифры-то поменялись? В конфиге уже был
Я добавил только и цифра общего времени упала до 1,6 сек.

Тогда вернулись с чего начинали, если это не БД, тогда что? Причем да, меня удивляло, что в цифрах в футере MysQL time: 0.109, Cache time: 0.14063, PHP time load modules: 1.125, а full time: 2.688. То есть, 0.109+0.14063+1.125 = 1.37463 != 2.688 Куда-то уходят еще 1.31337 сек.

И 1.125 сек на php на пустой странице? Это нормально?

Тогда вернулись с чего начинали, если это не БД, тогда что? Причем да, меня удивляло, что в цифрах в футере MysQL time: 0.109, Cache time: 0.14063, PHP time load modules: 1.125, а full time: 2.688. То есть, 0.109+0.14063+1.125 = 1.37463 != 2.688 Куда-то уходят еще 1.31337 сек.

На тот момент да. Я просто взял цифры из поста. Вот сейчас такие цифры:

И, кстати, все равно 0.04688 > 0.
И все равно, около секунды куда-то уходит, помимо перечисляемых потребителей.

Эм… Давайте разбираться. APC — это Alternative PHP Cache? Если стоит, то неочевидно для меня. XCache тоже вроде бы нигде не упоминается в конфиге. Сейчас тестирую на OpenServer: Apache/2.4.6, PHP 5.3.27, MySQL 5.5.33 (InnoDB), включен Memcached 1.4.5

Вы что думаете что только в «форейн ключах» разница между MyISAM и InnoDB? Любая DML операция в рамках MyISAM вешает lock на всю таблицу, что цитирую «Приводит к отсутствию масштабируемости, то есть к сильной деградации производительности с повышением нагрузки.»

Забудьте про существование MyISAM. Никогда не используйте MyISAM.

(хоть смена типа не помогла, спрошу на будущее) А вот если бы с myisam работало бы быстрее, можно ли было разрабатывать на ней, а потом при переезде на хостинг конвертировать это все в innodb и продолжать работать?

Еще пишут, что разница в нагрузочных характеристиках проявляется уже при довольно высоких значениях кол-ва посетителей. Можно ли без проблем конвертировать базу при достижении этих чисел?

а потом при переезде на хостинг конвертировать это все в innodb и продолжать работать?

внешние ключи для каждой таблицы сами будете назначать?

просто сконвертировать — можно, но это будет уже не та база, если она была изначально в иннодб.

а вот скорость работы заметно будет быстрее с MyISAM.

kpoxas… вы категорически заблуждаетесь во многом.

Во-первых MyISAM не хуже InnoDB в плане надёжности. Целостность данных и надёжность — это не одно и то же.

Во-вторых, просто в силу своей природы, при хоть какой-то параллельной нагрузке MyISAM проигрывает InnoDB в производительности всегда. И чем больше такая нагрузка — тем больше проигрыш. И с какого-то момента (high load), MyISAM умирает полностью.

Однако, бывают «single thread» конфигурации, для отдельного класса задач, и вот там — да, MyISAM имеет смысл. Но это совершено точно, не случай LiveStreet.

innodb_flush_log_at_trx_commit = 0 не убивает вам надёжность. C этой опцией вы имеете шанс потерять изменения за последние несколько секунд в случае краша MySQL демона или сервера. Ужасная потеря для LS :).

innodb_flush_log_at_trx_commit = 2 — тоже самое что выше, но только при краше сервера. Краш MySQL демона к потере данных не приведет.

Если вам innodb_flush_log_at_trx_commit = 0 помогает, а innodb_flush_log_at_trx_commit = 2 — нет, то это уже знак знак где копать. например в конфигурации лога: innodb_log_file_size?
Ну и innodb_locks_unsafe_for_binlog = 1 всё же рекомендую. 🙂