Выбор сервера под ноду

[kzv]

Ну как-то так )

Code:

dd if=/dev/zero of=/tmp/output bs=8k count=1000k; rm -f /tmp/output conv=fdatasync

1024000+0 records in
1024000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 53.2715 s, 157 MB/s

То есть, получается что внешний SSD примерно так же производителен, как и дисковый кэш в решении, использованном ранее для тестов. Я бы задумался, потому что это может значить только одно - хостинг провайдер занимается жестким оверселлингом и у него нет столько физической памяти для виртуалок, сколько он продал своим клиентам.

Получается, что рейд из двух HDD дисков не уделывает SSD на тестах с большими файлами. На тестах с маленькими файлами - уделывает.
Провайдер не может заниматься оверселлингом, потому что у меня выделенный сервер, а не виртуалка.

[Balthazar]

Получается, что рейд из двух HDD дисков не уделывает SSD на тестах с большими файлами. На тестах с маленькими файлами - уделывает.

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

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

Значит, что-то не так с параметрами ядра. Надо разбираться.

[kzv]

Получается, что рейд из двух HDD дисков не уделывает SSD на тестах с большими файлами. На тестах с маленькими файлами - уделывает.

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

Ну это как сказать...
Если у меня приложение работает с файлами до 100 мегабайт и получает скорость работы с диском на компе с ХДД в разы лучше чем на компе с ССД, то мне в принципе уже не столь важно - с памятью реально идет работа или с диском.

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

Значит, что-то не так с параметрами ядра, быть такого не может чтобы оперативная память на современном железе была медленнее SSD.

Вообще-то не факт, что это идет бенчмарк только памяти.

[Balthazar]

Ну это как сказать...
Если у меня приложение работает с файлами до 100 мегабайт и получает скорость работы с диском на компе с ХДД в разы лучше чем на компе с ССД, то мне в принципе уже не столь важно - с памятью реально идет работа или с диском.

Плюс один, сам довольно долго развлекался с 15к RPM HDD и непонимающе смотрел на "адептов" SSD, некоторое время. Для реального применения неважно, почему конкретная конфигурация работает быстрее другой конфигурации, или сравнимо с ней.
Но если хочется понять причины, то уже придется копать глубже. Потому что эти причины могут привести к совсем иному результату в чуть-чуть другом сценарии, не менее реальном.

Вообще-то не факт, что это идет бенчмарк только памяти.

Конечно. Тратится время процессора, тратятся циклы I/O на обновление метаданных ФС. Да и, в любом случае, данные оказываются на диске, по крайней мере большая их часть. А если и не оказываются на пластинах, то передаются диску по IDE/SATA или что там. Вот только контроллер, стоящий в диске - это не тупая железка, записывающая всё что ей скажут. Это целый компьютер с собственной ОС, снабженной довольно сложным набором программ, вся цель которых в предсказании действий хоста и планировании работы с головками, а также с локальным кэшем. Даже в ноутбучных сигейтах ставят чип DDR2 объемом 128мб, на энтерпрайзных дисках объем локального кэша ещё больше. Поэтому, запись 80мб данных - это нерепрезентативно.

[sNUM]

Синхронизировал ноду с параметрами geth --rpc --rpcaddr localhost --rpcport 8545.
Get attach выдает следующую информацию:
currentBlock: 9047250,
highestBlock: 9047318,
knownStates: 74141394,
pulledStates: 74137457,
startingBlock: 9047228
Но при попытке совершить трансфер токена erc20, получаю ошибку: (node:10856) UnhandledPromiseRejectionWarning: Error: Returned error: exceeds bl
ock gas limit
Синхронизировал на пк, в коде указывал:
const Web3js = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
Web3js.eth.getTransactionCount(fromAddress)
  .then((count) => {
    let rawTransaction = {
      'from': fromAddress,
      'gasPrice': Web3js.utils.toHex(20 * 1e9),
      'gasLimit': Web3js.utils.toHex(210000),
      'to': tokenAddress,
      'value': 0x0,
      'data': contract.methods.transfer(toAddress, amount).encodeABI(),
      'nonce': Web3js.utils.toHex(count)
    }
В чем проблема? Может все же нужно использовать полную ноду? Или же вот это отставание в <100 блоков так влияет?
При использовании ноды от infura транзакция выполняется.

[Balthazar]

Синхронизация ни при чем. У вас в транзакции потребляется слишком много газа, больше чем разрешено в блоке.

Таки при чем. См. ниже.

[sNUM]

А как объяснить то, что при на ноде infura все работает при таких же параметрах?
Или подскажите какие параметры нужно выставить?

[Balthazar]

А как объяснить то, что при на ноде infura все работает при таких же параметрах?

Понятия не имею. Версии демона одинаковые?

Вообще же не совсем понял, зачем вы себе создаете проблемы с RAW транзакциями там, где они не слишком-то нужны. Используйте простой sendTransaction и тогда не нужно будет ни nonce указывать, ни цену газа, клиент подставит всё сам. Или вы не доверяете серверу и на нем нет ключей?

[sNUM]

Думаю дело все же в синхронизации, https://ethereum.stackexchange.com/questions/24667/why-is-my-ether-balance-0-in-geth-even-though-the-sync-is-nearly-complete

[Balthazar]

Думаю дело все же в синхронизации, https://ethereum.stackexchange.com/questions/24667/why-is-my-ether-balance-0-in-geth-even-though-the-sync-is-nearly-complete

Мда. Похоже, что вы правы, уже сто лет не пользовался geth.

Насчет отправки транзакции, проще будет так:

const data = contract.methods.transfer(toAddress, amount).encodeABI();
web3.eth.sendTransaction({to:tokenAddress, from:fromAddress, data: data});

Но это если на сервере есть нужные ключи.

[sNUM]

Спасибо, попробую, видимо нужно искать сервер, ставил для тестов на пк, но видимо 16гб РАМ мало

[Balthazar]

Спасибо, попробую, видимо нужно искать сервер, ставил для тестов на пк, но видимо 16гб РАМ мало

Не нужно тратиться, geth это вечная альфа, которая никогда не будет доработана и всегда будет потреблять кучу ресурсов непонятно для чего. Поставьте parity, ему вашего десктопа хватит более чем. По API обратная совместимость с geth, почти все написанное для geth работает и на parity.

[sNUM]

Почитаю, буду пробовать, спасибо за помощь.