0 Пользователей и 1 Гость просматривают эту тему.
Массово появляется ошибка «Default domain could not be found». Причем не у всех а как-то вдруг. Безсистемно и разово. Появилась — обновил страницу все ok.

Записан
Как правило, такие ошибки возникают при проблемах с БД.

Записан
Это я догадался. А с чем может быть связано? У нас тут очень высокая нагрузка была под «черную пятницу» и с тех пор сайт колбасит откровенно.
Может переписать выбор этого самого дефаулта из базы на прямой запрос?
« Последнее редактирование: 02 Декабря 2014, 15:04:01 от arbuzzz »

Записан
Я бы сначала запустил cron.php и почистил базу от лишнего (при условии, что версия системы выше 2.9.6). Затем оптимизировал текущие макросы, после уже писал бы свой запрос.

Записан
Версия 2.9.1 и обновлению, к сожалению, не подлежит. Во первых кончилась лицензия, а во вторых несмотря на все старания обойтись без правок в системных файлах не получилось.
От мусора чищу запуском файла, который дали ребята их СЗ при переносе системы с 2.8.3 на текущую 2.9.1 Но чищу только заказы без названия, т.к. остальное — либо возвращает слишком малое кол-во результатов, либо вешается при попытке посчитаться (про удаление, да ещё и на боевом сервере боюсь даже подумать).
Оптимизация макросов мне кажется не поможет, т.к. ошибки возникают в процессе работе системных. Так ошибка возникает при выводе списка запросов в модуле интернет-магазина.

Записан
Плохо, что изменены системные файлы.
Оптимизация макросов сократит нагрузку на базу, что позволит остальному сайту работать чуточку быстрее.
Буквально сегодня закончил оптимизацию магазина одежды. Вывод всех объектов со скидкой до оптимизации занимал 16 сек. на VPS. После оптимизации — в пределах 2,5 (из-за того, что на странице одновременно выводится 150 товаров с фотографиями). Если добавить пагинацию, можно уложиться в 1 сек.
После того, как оптимизировал этот запрос, остальной магазин стал работать быстрее — https://docs.google.com/spreadsheets/d/12YxmYRGixfK0mtEduq3sHaol_tFCCUu7sSXRIuoACuk/edit

Записан
Плохо, что изменены системные файлы.
Оптимизация макросов сократит нагрузку на базу, что позволит остальному сайту работать чуточку быстрее.
Буквально сегодня закончил оптимизацию магазина одежды. Вывод всех объектов со скидкой до оптимизации занимал 16 сек. на VPS. После оптимизации — в пределах 2,5 (из-за того, что на странице одновременно выводится 150 товаров с фотографиями). Если добавить пагинацию, можно уложиться в 1 сек.
После того, как оптимизировал этот запрос, остальной магазин стал работать быстрее — https://docs.google.com/spreadsheets/d/12YxmYRGixfK0mtEduq3sHaol_tFCCUu7sSXRIuoACuk/edit
Меня фронтэнд не беспокоит. Для неадмина у меня страницы грузятся достаточно быстро. Страницы уходят через nginx с со статичным коротким (10 минут) кешем. Блок корзины обновляю по ajax.
А вот бекенд — это вилы. На сохранение карточки заказа уходит от 5 секунд, если товаров в заказе мало. Если их там в районе пары десятков (а бывает и до 40 с лишним), то сохранение карточки заказа может занимать до минуты и больше. А может и вообще ничего не сохранить.
Ошибка про default домен вылезает и в админке в том числе.

Записан
А вот бекенд — это вилы. На сохранение карточки заказа уходит от 5 секунд, если товаров в заказе мало. Если их там в районе пары десятков (а бывает и до 40 с лишним), то сохранение карточки заказа может занимать до минуты и больше. А может и вообще ничего не сохранить.
Ошибка про default домен вылезает и в админке в том числе.
Меня это наводит на мысли, что проблема у вас не в ЮМИ, а в сервере. Может быть, поломались индексы в БД. Может, сама БД разрослась. Места свободного на диске достаточно? Может, был сбой и теперь в памяти висят мертвые процессы.
Логи посмотрите на предмет ошибок; лог медленных запросов MySQL включите — надо понять что может так тормозить . Даже для ЮМИ у вас слишком медленно.
Похоже на то, что у вас сервер MySQL не успевает обрабатывать запросы.
Экспериментировать на боевом сервере я бы не рискнул, но ведь можно сделать копию на другом сервере и там развлекаться.

Записан
Буквально сегодня закончил оптимизацию магазина одежды.
А можете подробнее рассказать что делали?

Записан
Буквально сегодня закончил оптимизацию магазина одежды.
А можете подробнее рассказать что делали?
Напишите в skype e-ioffe

Записан
А вот бекенд — это вилы. На сохранение карточки заказа уходит от 5 секунд, если товаров в заказе мало. Если их там в районе пары десятков (а бывает и до 40 с лишним), то сохранение карточки заказа может занимать до минуты и больше. А может и вообще ничего не сохранить.
Ошибка про default домен вылезает и в админке в том числе.
Меня это наводит на мысли, что проблема у вас не в ЮМИ, а в сервере. Может быть, поломались индексы в БД. Может, сама БД разрослась. Места свободного на диске достаточно? Может, был сбой и теперь в памяти висят мертвые процессы.
Логи посмотрите на предмет ошибок; лог медленных запросов MySQL включите — надо понять что может так тормозить . Даже для ЮМИ у вас слишком медленно.
Похоже на то, что у вас сервер MySQL не успевает обрабатывать запросы.Экспериментировать на боевом сервере я бы не рискнул, но ведь можно сделать копию на другом сервере и там развлекаться.
default домен — я уверен, что какая-то проблема либо в базе, либо в кеш’ах.
Т.к. срок поддержки вышел, то обратиться в СЗ нельзя. Да и работают они в последнее время ка-то откровенно не очень.
А про скорость — дело реально в скидках. Если отключить поиск подходящих скидок при order->refresh() то скорость сохранения заказа вырастает в разы. Там тупой механизм — он берет все скидки и поочередно проверяет его для каждого элемента заказа. Если в заказе много позиций и база и так под нагрузкой, то обработка одной позиции в заказе занимает в районе секунды. При кол-ве позиций около 40 штук плюс время на обработку?отправку формы заказа, плюс время на получение результата и его отрисовку. Вот и получается время сохранения в районе минуты.
В медленных запросах самые все запросы, кроме тех которые выполняют полнотекстовый поиск, занимают не больше 2,5 секунд. Тоже не торт, но в базе очень много записей. phpMyAdmin показывает cms3_object_content больше 10Гб.

Записан
От мусора чищу запуском файла, который дали ребята их СЗ при переносе системы с 2.8.3 на текущую 2.9.1 Но чищу только заказы без названия, т.к. остальное — либо возвращает слишком малое кол-во результатов, либо вешается при попытке посчитаться (про удаление, да ещё и на боевом сервере боюсь даже подумать).
Правильно ли я понимаю, что чистку заказов, в итоге, не получилось сделать?
Это я догадался. А с чем может быть связано? У нас тут очень высокая нагрузка была под «черную пятницу» и с тех пор сайт колбасит откровенно.
Если был такой наплыв посетителей, наверно было создано много «брошенных корзин» и если чистку не удалось сделать, то у вас там много мусора, который чиститься как писал i.eoffe
Я бы сначала запустил cron.php и почистил базу от лишнего (при условии, что версия системы выше 2.9.6). Затем оптимизировал текущие макросы, после уже писал бы свой запрос.
Так как у вас не та версия, то можно тоже самое чистить и ручками, но начинают обычно все равно с заказов (и тут снова отсылка к моему первому вопросу)

Записан
- Remove From My Forums
-
Question
-
I am trying to join my computer with the 10074 build installed to my work domain through the «Join a Domain or Workgroup» wizard. An error box appears with the message «An Active Directory Domain Controller (AD DC) for the domain <domainname>
could not be contacted.» I didn’t have this issue with the previous builds I’ve used. The domain is hosted on a Windows 2008 server. Has anything changed in build 10074 that would cause this?-
Edited by
Friday, May 1, 2015 12:43 PM
-
Edited by
Answers
-
Hi,
We can manually set the preferred DNS server in 10074 to the address the DC, after that, I can successfully join my 10074 to my domain.
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.
-
Proposed as answer by
Yolanda ZhuModerator
Wednesday, May 13, 2015 7:14 AM -
Marked as answer by
Brandon RecordsModerator
Monday, May 18, 2015 8:09 PM
-
Proposed as answer by
We added a secondary domain controller to our domain that is a Server 2008 R2 std. There are 3 domains in the forest. Our main location, Domain1.com consists of 2 Server 2003 DCs and 1 Server 2008 DC. The 2k3 servers in Domain1.com are replicating with Domain2.com and Domain3.com but the 2008 server cannot communicate with Domain2 and Domain3 on the domain level. I am able to ping the DC’s at the 2nd and 3rd locations from the 2008 server.
If I try to view the other domains from the 2k8 server in Group Policy Management or Active Directory Users and Computers, I am prompted with the error «the domain could not be found because: the server is not operational» or «the specified domain either does not exist or cannot be contacted.»
The DCs at Domain2 and Domain3 seem to have no problem communicating with the 2k8 in Domain1. I ran repadmin to check for replication errors and the only errors are when 2k8 Server tries to replicate to DC’s in domain2 and domain3. The DCs in domain2 and domain3 are both 2k8 servers. I have tried turning off the firewall completely do see if that was part of the problem and there were no changes in the issue. I have also checked DNS info and can’t seem to find the issue.
Thanks for your assistance.
I follow the official document try to install openstack-keystone
openstack --os-auth-url http://192.168.80.6:35357/v3
--os-project-domain-id default --os-user-domain-id default
--os-project-name admin --os-username admin --os-auth-type password
token issue
Verify that the user can authenticate,error:
The request you have made requires authentication. (HTTP 401) (Request-ID: req-8d9e9608-2adb-4b80-bc00-f0fd9e9684ae)
I checked log find:
2017-10-04 09:06:40.966 1256 INFO keystone.common.wsgi [req-5a17f2ba-ce0e-46cb-8397-707ac9240870 - - - - -] GET http://192.168.80.6:35357/v3/
2017-10-04 09:06:40.982 1243 INFO keystone.common.wsgi [req-8d9e9608-2adb-4b80-bc00-f0fd9e9684ae - - - - -] POST http://192.168.80.6:35357/v3/auth/tokens
2017-10-04 09:06:40.987 1243 WARNING keystone.auth.controllers [req-8d9e9608-2adb-4b80-bc00-f0fd9e9684ae - - - - -] Could not find domain: default
2017-10-04 09:06:40.988 1243 WARNING keystone.common.wsgi [req-8d9e9608-2adb-4b80-bc00-f0fd9e9684ae - - - - -] Authorization failed. The request you have made requires authentication. from 192.168.80.6
I checked domain list
# openstack domain list
+---------------------------------+---------+---------+----------------+
| ID | Name | Enabled | Description |
+---------------------------------+---------+---------+----------------+
| 75391e2f3a1c4c8e94a82d05badb941 | default | True | Default Domain |
| 8 | | | |
+---------------------------------+---------+---------+----------------
I check configuration,or unless what I should do ?
thanks!
asked Oct 4, 2017 at 1:50
![]()
I think it has to do with using the project-id instead of project-name. The project name would be default, while the id would be 75391e2f3a1c4c8e94a82d05badb9418.
Change:
--os-project-domain-id default
to
--os-project-name default
or
--os-project-domain-id 75391e2f3a1c4c8e94a82d05badb9418
Update the —os-user-domain-id in the same way.
Give that a try and see if you are able to get a token.
answered Oct 4, 2017 at 15:46
![]()
I just upgraded to macOS 10.14.2, but the issue still persists.
This is my plist file (~/Library/LaunchAgents/com.buildkite.buildkite-agent-1.plist):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<!--
A launchd config for loading buildkite-agent on system boot on OS X
systems, and runs without GUI (which starts on system boot, but doesn't allow Xcode UI testing)
-->
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.buildkite.buildkite-agent-1</string>
<key>UserName</key>
<string>user</string>
<key>ProgramArguments</key>
<array>
<string>/Users/user/.buildkite-agent/bin/buildkite-agent</string>
<string>start</string>
<!-- <string>--debug</string> -->
</array>
<key>KeepAlive</key>
<dict>
<key>SuccessfulExit</key>
<false/>
</dict>
<key>RunAtLoad</key>
<true/>
<key>OnDemand</key>
<false/>
<key>ProcessType</key>
<string>Interactive</string>
<key>SessionCreate</key>
<true/>
<key>ThrottleInterval</key>
<integer>30</integer>
<key>StandardOutPath</key>
<string>/Users/user/.buildkite-agent/log/buildkite-agent-1.log</string>
<key>StandardErrorPath</key>
<string>/Users/user/.buildkite-agent/log/buildkite-agent-1.log</string>
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin</string>
<key>BUILDKITE_AGENT_CONFIG</key>
<string>/Users/user/.buildkite-agent/buildkite-agent-1.cfg</string>
</dict>
</dict>
</plist>
The buildkite agent is in the /Users/user/.buildkite-agent directory (default when following the Linux/other installation method) and it’s owned by user:staff:
macmini1:~ user$ id
uid=501(user) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh-disabled)
macmini1:~ user$ find /Users/user/.buildkite-agent ! -user user
macmini1:~ user$ find /Users/user/.buildkite-agent ! -group staff
macmini1:~ user$ launchctl list | grep build
macmini1:~ user$
I tried this on two different machines with macOS, but ran into the same problem.
This is the agent configuration (/Users/user/.buildkite-agent/buildkite-agent-1.cfg):
# The token from your Buildkite "Agents" page
token="xxx"
# The name of the agent
name="macmini1-1"
# The priority of the agent (higher priorities are assigned work first)
# priority=1
# Meta-data for the agent (default is "queue=default")
# meta-data="key1=val2,key2=val2"
# Include the host's EC2 meta-data (instance-id, instance-type, and ami-id) as meta-data
# meta-data-ec2=true
# Include the host's EC2 tags as meta-data
# meta-data-ec2-tags=true
# Path to where the builds will run from
build-path="~/builds-1"
# Directory where the hook scripts are found
hooks-path="/etc/buildkite-agent/hooks"
# Do not run jobs within a pseudo terminal
# no-pty=true
# Don't automatically verify SSH fingerprints
# no-automatic-ssh-fingerprint-verification=true
# Don't allow this agent to run arbitrary console commands
# no-command-eval=true
# Enable debug mode
# debug=true
# Don't show colors in logging
# no-color=true
# Clean all the things!
git-clean-flags=-ffdxe_build
# add linux=true tag to target based on os
tags="osx=true"
the agent configuration has to be okay, since I can start the agent manually just fine, like this:
macmini1:~ user$ cd .buildkite-agent && bin/buildkite-agent start --config buildkite-agent-1.cfg