orange_blue, ну там же написаны все характеристики русским языком. Максимальная длина видяхи. Макс высота процессорного куллера, рекомендуемые мат платы и тд. Как видите всё подходит (но куллер особо крутой на проц тоже не воткнёшь. хороший куллер может быть 168мм и более).
Но будет всё в упор дышать в друг дружку. С таким корпусом нормальную СО не построишь особо. В этом корпусе у вас будет жарища мама не горюй (тем более щас лето) и через недельку вы всё равно купите нормальный корпус пойдёте. В чём проблема взять нормальный корпус для вашего железа? https://technopoint.ru/product/7053a688580e3120/ko...
driverx18, ну так вы покажите нагрузку на сервак в этот момент и до него чтобы понимать чего там. Вы не предоставили графиков ни top ни htop. Даже не озвучили характеристики сервака (может у вас там сервак не мощнее смартфона 3х летней давности). Удалённо не видно что происходит.
driverx18, У нас 2млн юзеров и ну у нас сначала 1-100id идёт потом 101-201 потом 202-302 итд и всё норм. Да наверное правильно поняли.
Попробуйте по 10 слать (может он и от 10 писем будет лагать) а не по 100 для начала. Может дело не в количестве а дело в неправильной логике и тд. Надо более подробно смотреть что в этот момент происходит почему лагает бот
neol, он хочет больше инстансов чтобы я выставил. Но этого не требуется.
1 дедлок не могу разрулить.
Deadlock found when trying to get lock; try restarting transaction
1213
UPDATE `tb_ads_dlink_visits` SET `status` = \'1\', `money`=\'0.05082\', `date`=\'1553494215\' \n WHERE `idu` = \'315158\' and `status` = \'0\' and `ids` = \'8098913\'
не понимаю почему получается тупиковая ситуация. В SHOW ENGINE INNODB STATUS:
spoiler
TRANSACTION 23360043, ACTIVE 0 sec fetching rows
mysql tables in use 3, locked 3
LOCK WAIT 31 lock struct(s), heap size 3520, 152 row lock(s)
MySQL thread id 57710575, OS thread handle 139944620435200, query id 425634012 192.168.1.2 xxxxxxxxx Searching rows for update
UPDATE `tb_ads_dlink_visits` SET `status` = '1', `money`='0.05082', `date`='1553494215'
WHERE `idu` = '315158' and `status` = '0' and `ids` = '8098913'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2017 page no 3180 n bits 296 index PRIMARY of table `basename`.`tb_ads_dlink_visits` trx id 23360043 lock_mode X locks rec but not gap waiting
Record lock, heap no 164 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
rsenmakh, Вы не первый человек кто говорите что ifы зло.
Хоть это даже и написано на офф сайте. Скорее всего это брехня всиволовой кобылы.
У меня на проекте всё в if в конфе nginx и всё работает как часы при 120 000 уников в сутки среднем онлайне 8 000 чел. И я когда сам заморачивался убирал их по производительности и по нагрузкам разницы не увидел.
Может даже если есть разница в 0.00001% то её никак не заметить даже софтовыми средствами. Конечно если у тебя 1000 if то это зло. А если 5-20 то пофигу.
Тем более надо чтобы этот if выполнялся их хоть как то напряг nginx вам надо на яндексе повешать на главной баннер ведуший на https://domainname.com/index.php чтобы принять hight траф, но и тут загнёться быстрее интернет канал /БД вашего сервера чем nginx. Так что брехня это всё.
ИМХО!
выполни mysqlcheck --auto-repair --optimize --all-databases
и смотри mytop и slow_query_log=1
slow_query_log_file=/var/log/mysql-slow-queries.log