ScriptKiddo

Рискну предположить, дело в том, что для обработки блока с одним nonce требуется много операций хеширования. SHA-256 "ест" по 512 бит за раз, а размер блока около мегабайта. Плюс в BTC считается двухкратный хеш SHA-256(SHA-256(Data)).
Но даже с учётом всего этого цифры не сходятся где-то на 2-3 порядка.

UPD. Нашёл. Помимо nonce, в блок ещё входит timestamp. Его можно менять в довольно больших пределах, не нарушая валидности блока (он должен быть больше, чем медиана времени предыдущих 11 блоков и меньше, чем средне-сетевое время +2 часа). Прогнав весь диапазон nonce и не получив красивого хеша, майнер немного меняет timestamp и прогоняет весь диапазон nonce заново. А потом снова и снова, пока не попадёт.
Весь диапазон валидных timestamp почти 3 часа ~10^4 секунд. Теперь вроде сходится.

Касательно mysql знаю три варианта:

1. Утилита pt-online-schema-change. Создаёт пустую копию исходной таблицы, делает на ней alter, копирует данные из исходной таблицы и в конце меняет местами старую и новую таблицы.

Пользовался этой утилитой пару раз. Хорошо работает.

2. В mysql 5.6 появилась возможность делать alter без блокировок средствами самой субд. Нужно в alter добавить парочку новых параметров:

ALTER TABLE tbl_name ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;

Этот вариант я сам не пробовал, поэтому прокомментировать не могу.

3. Самый сложный вариант с использованием двух инстансов mysql, связанных master-master репликацией:

1. Делаем alter на втором сервере
   
2. Ждём, когда второй сервер догонится по репликации
   
3. Переключаем сервис на вторую базу
   
4. Ждем какое-то время, смотрим, нормально ли приложение работает с новой схемой, нет ли деградации или ошибок
   
5. Делаем alter на первой базе
   
6. Ждём догона репликации
   
7. Возвращаем сервис на первую базу
   

С этим вариантом я работаю постоянно. Выглядит просто, но на деле много нюансов.

Нужно обязательно пропускать alter мимо репликации:

SET sql_log_bin = 0;
ALTER TABLE tbl_name ...;

Важно не забыть про sql_log_bin = 0, иначе alter по репликации переедет на соседний сервер и залочит таблицу уже там. А переключать сервис нельзя, пока репликация не догонится.

Если меняется структура таблицы - добавляется/удаляется колонка или меняется их порядок, нужно обязательно проследить чтобы тип репликации обязательно был STATEMENT. Иначе репликация приляжет на первом же запросе в формате ROW с примерно такой странной ошибкой:

Column 25 of table 'mydb.mytable' cannot be converted from type 'varchar(255)' to type 'bigint(20) unsigned'

А со STATEMENT нужно следить чтобы приложение нигде не понижало уровень изоляции ниже REPEATABLE READ, иначе получит ошибку:

Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.

Точки имеют специальное значение в SQL запросах. Никто не делает SET ip = "+z+" WHERE, и даже format не делают, и f строки тоже не используют

Читайте хоть документацию как работать с sql, наугад зачем
https://www.sqlitetutorial.net/sqlite-python/update/

Это тоже
if res == [(None,)] or [(''),]:

cursor.execute("UPDATE ip_adress SET ip = ? where rowid = 1", (z,))
db.commit()

Если КПД 90% (на вход и выход), то 3 повербанка по 10А*ч по такой схеме дадут:

3й - 10000*0,9 =9000 (разряд 3го)
2й - 10000*0,9*0,9*0,9 = 7290 (разряд 2го, заряд 3го, разряд 3го)
1й - 10000*0,9*0,9*0,9*0,9*0,9 = 5904,9 (разряд 1го, заряд 2го, разряд 2го, заряд 3го, разряд 3го)

Итого 22195мАч или 74% полезной ёмкости.

Вот таблица для расчёта

Скролить категорически не рекомендую! Представьте, что там +100500 страниц. И если скролить, через некоторое время закончится оперативка, и кроме парсера, зависнет еще и компьютер.

Вместо этого, лучше к ссылке добавить параметр "?page=1" - где число - номер страницы. И в цикле увеличивать число, пока на странице не появится текст вроде - "В этой категории нет ни одного товара."

1. Загрузить процессор на MSSQL можно так :
- Должна быть задача на SQL серваке, которая потребует этих ресурсов (в простое или при малых задачах SQL проц не загрузит)
- Ставим параллелизм = количеству ядер
- Ставим Стоимостной порог в 0.
После завершения текущих проверок, советую вернуть MAXDOP/MaxThreshhold на (1/4 или 1/8 от количества ядер а порог выявить методом проб и замеров). Дело в том, что загрузка проца 100% не значит что всё будет быстрее (только в некоторых случаях типа проверки целостности). Т.к. при распараллеливании запросов по ядрам, появляются "Накладные расходы" на распараллеливание и сбор обратно результатов воедино. Это будет выглядеть как ожидания CXPACKET и Latch. (См "закон Амадала" + CXPACKET в гугле)
2. "Проверка целостности базы данных" - на ежедневной основе смысла не имеет, особенно если база достаточно крупная. Её имеет смысл делать или при возникновении проблем, или раз в квартал/месяц ... зависит от размеров базы. UPD: Лучше всё же её делать, если позволяет размер и тех. окно. Т.к. можно упустить ошибку целостности и перенести её в бэкап.
3. Если есть проблемы с производительностью, это вопрос не простой, и требует кучу опыта. Навскидку рекомендую сначала проверить :
- Нагрузку на дисковую подсистему, и если там будет проблема (Очередь к диску более 2 в среднем) выполнить разнесение *.mdf, *.log, tempdb, инстанс кластера 1c серверов на отдельные диски.
- Нагрузку на оперативку от MSSQL (можете гуглить это может вызывать большую активность IO на дисковую подсистему)
- Проверить способ коннекта к MSSQL ("Shared memory" должно быть "on" и использоваться, если 1с сервак и mssql сервак физически на одно машине .. это +10% к производительности.
ну и куча чего ещё ... в одном посте всего не расписать.
и т.д. вариантов очень много.
главный совет: решайте проблемы , только если она есть и мешает, если это лично ваше мнение, а пользователям не мешает, лучше делайте настройки по дефолту (см. APDEX, анализ производительности)
UPD: И да, виртуалки для 1C + MSSQL = зло, и не потому что "фирма 1С плохая", а потому что у вас не сможет 1С и MSSQL не сможет общаться через оперативку, и между оператором чтения на MSSQL до железа сервера будет 4 прослойки (SQLOS, OS виртуалки, Гипервизор, OS сервера, вместо SQLOS + OS сервера).

command - строка, все проверки условий в if возвращают bool значение.

По сути, проверка выглядит примерно так:
if not bool(command):

bool от пустой строки вернет False, если строка не пустая - True
not - логический оператор, который возвращает True, если утверждение не True. В общем возвращает противоположное значение

Ну то есть

>>> not True
False
>>> not False
True

Если вводится пустая строка
if not bool(command):
, то условие выглядит как
if not False:
(потому что bool от пустой строки возвращает False). В свою очередь, not False возвращает True. В итоге конструкция превращается в
if True:
и условие выполняется.

Если строка не пустая, то соответственно будет if not True и затем if False, условие не выполнилось.

Так что, если строка пустая - цикл пропускает.

Водянка - это для тех, кто не наигрался в конструктор. Дорого, не надежно. Какой-то существенной разницы в температурах или в уровне шума там нет.
За 70 евро можно купить такие суперкуллеры как GamerStorm Assassin III, Thermalright Macho Rev.B... Еще чуть добавить - вот вам и be quiet! DARK ROCK PRO 4.
Каждый из них легко справится с вашим процесором и даже шуметь не будет.
Или раскошелиться на Noctua NH-D15 или Thermalright Silver Arrow IB-E Extreme Rev. B - не каждая водянка их обойдет.
Я не предлагаю мне верить на слово - посмотрите тесты Thermalright Macho Rev.B и сами решите - стоит ли геморой с водянкой этих градусов.

Конечно можете. После await у вас должен идти промис, который будет ресолвиться из обработчика события. Если речь о событиях DOM, то как-то так:

HTMLElement.prototype.waitFor = function(event_name) {
    if (event_name) {
        return new Promise((res, rej) => {
        	const listener = function() {
        		res()
        		this.removeEventListener(event_name, listener)
        	};

        	this.addEventListener(event_name, listener);
        })
    } else {
        throw 'No event passed to waitFor method!';
    }
}

async function foo() {
	const start = new Date();
	await document.querySelector('body').waitFor('click');
	console.log('uspeshno dojdalis clicka, jdali celih ' + ((new Date().getTime() - start.getTime())/1000) + ' sekund');
}

foo();