Друпалеру на заметку

lexa - 06/Мар/2011 19:49

Если у вас по каким-то причинам есть запись в таблице node, но нет ни одной записи с таким nid в node_revisions, то у вас ВНЕЗАПНО начнут портиться права доступа. Причем rebuild permissions будут помогать ненадолго, до попытки создания очередной node.

Детектируется проблема элементарно:

 select nid from node n where not exists (select nid from node_revisions r where r.nid=n.nid);
Лечится - таким же delete.

Но я сегодня чуть не фалломорфировал, разбираясь.

Почему создание записи с revision не обернуто в транзакцию - мне удивительно, но подозреваю что это привет от MySQL.

Comments

Anonymous (not verified) - 06/Мар/2011 23:40

Было бы желание у пЕсателей, и в мыскуле бы смогли бы транзакцию сделать. Просто привыкли к автокоммиту, любители .DBF-переростка.

dil (not verified) - 07/Мар/2011 14:37

У меня случился тяжелый затык. Я пытаюсь написать программу на CUDA, которая должна тупым перебором инкрементируемого аргумента выделить те его значения, на которых некая функция выдаёт положительный результат. Сама функция нетривиальная, но считается довольно быстро, многие десятки миллионов в секунду получаются. Искомых значений аргумента на несколько порядков меньше, чем их всего проверяется, но сильно больше одного.

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

Простейший условный оператор if (res !=0) { дописать arg в возвращаемый массив } сокращает производительность на несколько порядков. Это даже без использования семафора, который по-хорошему таки нужен.

Ты случайно не знаешь, как принято поступать в подобных случаях?

lexa - 07/Мар/2011 15:19

Я не вполне понимаю твою задачу, но вот например:
- писать в выходной массив всегда (пару вход/результат)
- потом их отсортировать по результату.

У тебя же проблема не только в if(res) но и в том, что счетчик надо считать из глобальной памяти, потом записать что-то куда-то (относительно рандомная локация в рамках треда), потом и счетчик записать тоже.

dil (not verified) - 07/Мар/2011 16:44

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

lexa - 07/Мар/2011 17:52

А сколько этих самых ненулевых результатов, ну примерно?

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

Если их относительно много - то накопить все результаты и потом, отсортировав, выкинуть ненужное - будет быстрее.

dil (not verified) - 07/Мар/2011 17:54

примерно один-два на миллион

lexa - 07/Мар/2011 18:33

И что if(..) globalArray[atomicAdd(&counter,1)]=index тормозит весь процесс на порядки? Удивительное рядом.

dil (not verified) - 07/Мар/2011 18:43

Даже не atomic. Простая условная запись даже в одну и ту же ячейку тормозит процесс на порядки.
if(match) {
matchingArgs[0] = arg;
}

arg представляет собой unsigned char[8].
matchingArgs - глобальный массив, объявленный с атрибутом __device__. (Если быть совсем точным, это часть структуры, состоящей из счетчика, семафора, флага переполнения и собственно массива, но не думаю, что это принципиально).

А если написать if(1), что вероятно оптимизируется компилятором в отсутствие if вообще, то торможения практически нет. То есть, проблема не в самой по себе записи, а именно в её условности.

Так существуют какие-то идеологически более правильные способы возвращать такие наборы результатов?

lexa - 07/Мар/2011 19:00

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

А че профайлер говорит про это? Он, конечно, не operator-level (уроды), но об какое место тормозит можно, наверное, понять.

dil (not verified) - 07/Мар/2011 19:04

вот насчет предикатов непонятно. в мануале написано, что так могут оптимизироваться операции из 4-7 команд, а сколько занимает копирование 8 байт, я не знаю.
В любом случае, это быстрая опреация, пусть бы остальные треды в это время постояли, это на общем фоне сущая мелочь, а оно почему-то страшно тормозит.

Профайлер еще не пробовал, за идею спасибо, она мне почему-то в голову не пришла :)

lexa - 07/Мар/2011 19:21

А я тут подумал, куря на балконе, что если у тебя результат вызова функции нигде не используется, то не мог ли оптимизатор просто весь этот вызов спилить вникуда?

dil (not verified) - 07/Мар/2011 19:24

Функция имеет тип void, а результат возвращает в переменную через переданный ей указатель. Если компилятор решил такое заоптимизировать в ноль, то его аффторов надо гнать погаными тряпками вон из профессии.
Надо будет проверить, правда ли это..

lexa - 07/Мар/2011 23:03

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

Но тогда запись *всех* результатов в global mem - тоже должна быть "медленной" в том смысле, что не оптимизированной в ноль

dil (not verified) - 08/Мар/2011 00:31

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

lexa - 08/Мар/2011 10:20

Если ты пишешь в глобальную память все результаты и если только "позитивные" - второй вариант сильно медленнее, при том что позитивных одна миллионная?

dil (not verified) - 08/Мар/2011 11:27

Именно так.

Чтоб было понятнее, о чем речь, вот тестовый пример: http://dil.pp.ru/xfer-test.zip

Если вообще ничего никуда не писать (возможно при этом проверяющая функция вообще не вызывается, потому что результаты её работы не используются и побочных эффектов нет): 1644 миллиона проверок в секунду.

Если у функции включить побочный эффект в виде инкрементирования элемента глобальной структуры (инкрементирование работает, его видно потом в хосте): 1497 миллионов проверок.

Добавляем безусловное инкрементирование другого элемента глобальной структуры после вызова функции: 1320 миллионов.

Переносим это инкрементирование внутрь if(1): ничего не меняется.

Меняем условие на if(result): скорость уменьшается в три раза, 467 миллионов/c.

Не так заметно, как на живой программе, но всё же.
Пока все треды писали, они писали быстро. Потом большинство писать перестало, а оставшееся меньшинство стало писать втрое медленнее. Фигня какая-то..

lexa - 08/Мар/2011 11:45

Не, ну это ненастоящий код, ты же пишешь по одному адресу в __device__. Че там с (например) кэшами и конфликтами вообще неясно.

dil (not verified) - 08/Мар/2011 18:09

Кэшироваться должно хорошо, я ж в одно место пишу :)
С конфликтами в случае безусловной записи должно быть ещё хуже, все треды пишут одновременно, а с условием только очень некоторые. А получается всё равно сильно медленнее.

Dmitriy (not verified) - 05/Июл/2011 17:35

Доброго времени суток. У меня обнаружилась проблема - один в один, как описано, скорость также падает в 3 раза. Если вы разрешили проблему - пожалуйста, опишите в трёх словах, в чём причина падения скорости

kerozin (not verified) - 07/Мар/2011 18:07

Но сам факт буквально всенародной любви к мусклю при том, что есть более-менее нормальная реализация sql - необъясним.

lexa - 07/Мар/2011 18:33

Объясним, это DBF 21-го века!

kerozin (not verified) - 09/Мар/2011 05:09

Я думал на эту роль назначен SQLite.

lexa - 10/Мар/2011 09:51

Про SQLite не все знают.

dimas - 07/Мар/2011 20:21

На самом деле очень просто объясним. Берем шаред хостинг, и смотрим сколько хостеров дают мускуль, а сколько - постгрес ...

Anonymous (not verified) - 07/Мар/2011 20:53

А любов хостеров к мыскулю ты чем объяснишь? "Берём..." -- что?

dimas - 07/Мар/2011 20:57

дешевизной миннимально достаточного решения? :)

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

Anonymous (not verified) - 07/Мар/2011 22:56

Да не, современный мыскуль уже почти хорош в плане транзакционности. Другое дело, что нормальные запросы там бывает сложно написать, но последователям .DBF не привыкать. Собственно, фиг с ним, с мыскулем, раз уж пЕсатели его выбрали, но можно же иногда без автокоммита работать?

renat (not verified) - 07/Мар/2011 18:21

Это, я так понимаю, в шестерке? Надо будет посмотреть, сохранился ли этот баг в семерке, там работа с БД существенно переделана, в том числе и в части поддержки транзакций.

lexa - 07/Мар/2011 18:34

Не так и просто на это налететь, обычно оно на полдороге не ломается.

Но ломается - да, больно.