Есть база УПП, размер в SQL - 17 гигов, количество пользователей - 70 в пике. Партии выключены, ибо возникают постоянные блокировки и тормозит всё. На sql проводятся регулярные работы по расписанию: переиндексация, обновление статистики, обрезка лог-файла...

Провел эксперимент. Выгрузил базу в файловую версию и запустил проведение по партиям за 1 месяц по одному подразделению, получилось 1057 документов.

Файловая версия прогонялась на Core i5 760, 4 гига оперативки, обычный винт 7200 оборотов
Сервер стоит хороший - Xeon X5550 2.67 ГГц, 24 гига оперативки, винты в рейде-10, скорость винтов 10000 оборотов. Ничего кроме базы там не стоит, сервер приложений 1С на другом сервере.

Результат. Документы в файловой версии провелись за 7 минут 100%, sql за это время лишь 21 документ осилил. Итого 1057/21 = 50. Файловая база быстрее в 50 раз!

При этом общая загрузка процессоров SQL всего 10-15%. Пользователей в базе сидело 55 чел, но нагрузка шла только от меня, остальные ничего не делали.

Почему может ТАК тормозить sql версия? Куда "копать"?

небось файловая была в монопольном?

а вообще смотри SQL на предмет блокировок

>>> небось файловая была в монопольном?
Нет, в обычном режиме.

а ты запусти в файловую 50 юзеров, которые "ничего не делают" + Н юзеров, которыые ничего не делают на серверах (если они не выделенные). + если самописка/криводопилка без учета клиент-серверной технологии, то данные в холостую с клиент а на сервер гонятся могут (а на файловой этого не будет). + загрузка сети еще влияет

(0) Никуда. так и должно быть.

а настройки скуля и баз в скуле?

а кто сказал, что серверная база должна быть быстрее??? она только параллельнее

проблемы с сеткой может?

(6) ну не в 50 же раз

Прям америку открыл

(8) А во сколько? А вообще попробуй перегрузи сервер предприятия, может он тупит

>>> а настройки скуля и баз в скуле?

Что именно интересует?

>>> а кто сказал, что серверная база должна быть быстрее??? она только параллельнее

ну сколько я работал в других местах, sql всегда была быстрее файловой.

>>> проблемы с сеткой может?

сам грешу только на это...

(0)потому что гладиолус!

>>> А вообще попробуй перегрузи сервер предприятия, может он тупит

пробовали и переустанавливать сервер приложений и sql сервер с чистого листа - ничего не меняется.

(0)
1) надо делать почаше переиндексацию
2) шринк базы
3) перезапускать сервер 1С перед перепровдеением.
4) использовать восстановленеие последовательностей, а не прямо перепроведение каким то обработками.

Более того, когда делали центральную базу, пока размер позволял, выгружали в файловую перепроводили и выгружали на скуль обратно. По времени это занимало меньше, чем перепроводка на скуле (даже с учетом выгрузки и загрузки).

(10) >> ну сколько я работал в других местах, sql всегда была быстрее файловой.

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

(9) не буду я ничего перегружать, у меня проблем таких нет

(10) "sql всегда была быстрее файловой." - ты первый у кого так.

ПОследнее очень важно. У меня база под 30 гиг. перепроводится сама по ночам. обычно 2 месяца проводит за ночь. документооборот 2000 доков в день.

ВОсстановление последовательностей работает в фоновом режиме.

срочно переходи на файловую!

Правда не УПП. УПП вообще считаю жутким тормозом. регистры, планы счетов...если все сделано по проведению локов то да...

>>> "sql всегда была быстрее файловой." - ты первый у кого так.

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

(0) Скорее всего проблемы с сетью. 21 документ за 7 минут это не нормально!
И, как я понял, файловая база на локальном компе, как тут сравнивать можно. Ты её на сервере в файловом варианте разверни и проверь :):):)

(22) Да. Это было и в 7-ке и в 8-ке

SQL сервер никогда не давал увеличение скорости, только масштабируемость

(0) >> На sql проводятся регулярные работы по расписанию: переиндексация, обновление статистики, обрезка лог-файла...

По какому расписанию? Как часто? Лог-файл не режьте, переводите базу в simple, либо настраивайте бэкапы журнала транзакций.

Где лежит tempdb? Пробовали мониторить загрузку (очереди) на дисках с базой, логом, tempdb, файлом подкачки?

1 юзер в файловой против 50 в иквеле. Ну и сравнение. п..дец

(22) УПП какая и SQL?

Файловая в однопользовательском режиме однозначно быстрее клиент-серверного. Но не в 50 раз. Я бы посмотрел счетчики в 1С-е, где именно падение

>>> По какому расписанию? Как часто? Лог-файл не режьте, переводите базу в simple, либо настраивайте бэкапы журнала транзакций.

Раз в сутки по ночам все делается. База в simple и так.

>>> Где лежит tempdb? Пробовали мониторить загрузку (очереди) на дисках с базой, логом, tempdb, файлом подкачки?

Структура SQL сервера такая, всего 8 винтов:
диск С - 2 винта в рейде-1, стоит винда, сам sql и tempdb
диск D - 2 винта, рейд-1, лог файл
диск Е - 4 винта, рейд-10, база

>>> 1 юзер в файловой против 50 в иквеле. Ну и сравнение. п..дец

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

>>> SQL сервер никогда не давал увеличение скорости, только масштабируемость

Пускай. Но не падение скорость в десятки раз же! Иначе зачем масштабируемость такой ценой?

На отчетах файловая нервно в сторонке стоит и курит. в любых вариантах.

(32) *Но не падение скорость в десятки раз же
сервер слабый для такого количества юзеров (70 в пике), вот и...

рейд 1 для лога и темпдб?????????????

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

(0) Когда 1 пользователь (процесс) файловая действительно шустрее в разы. Когда их 50 - тогда совсем наоборот....
Адекватности сравнения есть 2 мысли:
1.раз уж в сиквельной 50 юзеров - то и в файловую нужно было запустить столько-же.
2.точно определить чем кроме проведения занята 1С может помочь технологический журнал!

Есть ещё специально для решения именно таких вопросов программа 1С:ЦУП (Центр Управления Производительностью). Но денег стоит!

(30) Попробуйте посмотреть очереди к дискам во время проведения.
Какого размера лог-файл перед началом операции? Он начинает расти во время проведения? Какое значение autogrowth для него стоит?
Кстати, пропустил, сервер 1С и sql server на одной машине? Никто из них не свопится?

>>> Ты её на сервере в файловом варианте разверни и проверь :):):)

Проверил, положил файловую базу на тот же винт, где база sql лежит. Провелось за 11 минут вместо 7, а sql так и корячится...

>>> Какого размера лог-файл перед началом операции? Он начинает расти во время проведения? Какое значение autogrowth для него стоит?
Кстати, пропустил, сервер 1С и sql server на одной машине? Никто из них не свопится?

Лог файл не изменился после проведения.
Да, на разных. Сеть 1 гигабит, загрузка во время проведения 1-2%.

Escander, пробовал тестировать при одном юзере, т.е. мне, все тоже самое. Вечером ради спортивного интереса еще раз запущу.

>>> сервер слабый для такого количества юзеров (70 в пике), вот и...

Если он слабый, почему нагрузка на процы выше 30% не поднимается никогда? Памяти свободной тоже есть.

>>> рейд 1 для лога и темпдб?????????????

Нам мегаспец sql так настроил. Сказал, что лучше бы для всего по своему рейду сделать. Но у нас всего 8 винтов, из них он сделал лучшее на свой взгляд.

>>> Провелось за 11 минут вместо 7, а sql так и корячится...

Соврал, 8 минут (Старт 25.01.2011 10:12:45, Финиш 25.01.2011 10:20:10.), т.е. тоже самое. Нагрузка сети как на серваке, так и мну на машине 2% максимум была.

(39)  а 50 рыл в неё в это время запустил?

Теперь загони в файловую 50 юзеров и заставь че-нидь делать...

(0)
укажите версию упп и платформы.

запустите файловое проведение по сети с двух машин.
вот тогда можно будет поговорить о скорости.


конечно многое зависит от сети.

если клиент запускался по сети + сама сетевая ифраструктура слабая (дешевая) то тормоза - норма.


по своему опыту скажу, что 1с 8.1 как минимум в 2 раза
быстрее делает выборки из ms sql версии, чем файловая по сети ПРИ УСЛОВИИ, что в базе работаю от 5 человек.

2 строят отчет, 2 вводит накладные, 1 - тестовая нагрузочная .

А пробовал выгружать/загружать базу на скуле? ведь при этом происходит много замечательных вещей, переиндексация, например)

(42) Потому что дело не в процах.

Я вот сегодня ночью запустил 10 баз в которых запустил пометку удаления. Параллельно обмен шел (файлик чуть более 1,5 гига). Параллельно еще одна база на 8.2 перепроводилась. И как то подтормаживало все. Хотя загрузка проца клиента 2-4%, загрузка сервера предприятий 12-15%. И скуль сам был загружен на 25-30%

(48) C каких пор процы для субд основное? Основное винты ...

(49) Ссылку на номер видел? Это был ответ на вопрос в (42), что нельзя все мерить процами

А винты .. на отдельной полки, так что там все ОК.


Хотя к примеру 7-ка тоже тормозила сильно, особенно когда под сотню рыл в базу зашло. Перенесли временные файлы на рам-диск - залетало

даю прогноз: если под базу сделать не 4 диска в 10-ке, а 6, то будет быстрее.

(50) чукча писатель :)

а ответ почему.

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

тема интересна. подпишусь.

Эксперимент №2.

Создана копия sql базы. Файловая база помещена на тот же сервер, на тот же винт, рядышком с sql. В обеих базах я единственный пользователь. Результат практически тот же - 1057 в файле против 34 в sql.

Эксперимент №3.

В тестовую sql-ную базу сделал загрузку из dt-шника. Результат не изменился: 1057 против 34.

(55) повторю описанную выше мысль
скуль вариант у вас разнесен на 2-х машинах (скуль сервер и сервер 1с) - т.е данные по сети гоняются во втором случае файловой базу у вас все на одном компе крутится)

если уж есть время проведите эксперимент 4 - запустите файловую базу находящуюся на диске скуль сервера с экзешника 1с находящегося на сервере 1с))) это уже интереснее будет

с 7-кой вообще без разговоров там однозначно медленнее скульный вариант - но был один жирный плюс если база большая никаких переиндексаций в монопольном режиме делать не надо)))

(55) а провести 1сный замер производительности не? счетчики производительности виндовые гляньте

(57) +т.е. теряли на скорости но выигрывали на паралельности и надежности)
это я про типовые - а уже "подкрученая" 1с 7.7 начинала летать

(55) счетчики производительности, что говорят?

какая длинна очереди к диску и какой размер памяти потребляет sql
и сколько воообще на сервере ОЗУ
и какой размер базы?

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

кстати, да...
какая версия УПП...
а то тут может вообще 1.1 стоит

спасипо  за ваще НЕравнодушие.

НО

Вы не понимаете разницы между
доступом к данным между 2 уровневой системой  (зазчик- данные или заказчик данные по  сети)

и 3 уровневой (заказчик-сервер приложения-серверСУБД-(данные))

сответственно при пяти пользователях записсь(блокировка всей талицы) быстрее, прр 10 медленее.


условие эксперимента сеть клиент сервер(приложеня, файловый)  100 бегабит sas 10 4

сервер приложения сервет субд (ms sql) 400 mgabit
sas raid 10 6  



чтение всегда будет быстрее.

тогда
по (46)
можно говорить о разнице.

иначе нужнно  описывать сотнощение операций ввода к опирациям вывода.

У меня СКЛ быстрее работает !

На уровне 1С не смотрел где тормозит ? - запросы ??

(63) на полтора порядка сервер 1 тормозит выполнение? чудес не бывает.

(56) +100
Неоднократно встречал отзывы, что даже на настроенной прямыми руками связке двух серверов (приложений + сиквел), наблюдается существенное замедление (по сравнению с вариантом, когда оба на одной железяке). А если не сильно прямыми - тогда вообще кури бамбук.

(67) +100
У мну в филиале умудрились так сетку настроить, что мд-шник в полтора десятка мег копируется с одного сервака на другой 4 минуты. И мне потом выдают: "твоя 1С-ка дико тормозит и вообще не запускается".

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

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

файловая? выбирает план?

хотя может конечно и выбирает... но как это проверить? как обновить статистику?

(71) и закуривает его.. сама...

(71) канешна, потом его забивает, и оттягивается..

(72) обычные дбф файлы врезанные в их 1 файл..

2(75) пруфлинк?

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

понятно...

(72) про технологический журнал уже писал!

ограничение в 4 гб никак не доказывает и не опровергает того что формат - дбф.

Готов забиться на бутылку спирта, что нету в файловой никаких планов. Вернее - они однозначны. Попой чую, кто никто не стал бы под файловую свой оптимизатор запросов рисовать.

Соответственно, и статистики никакой нет.

2(82) дык понятно, но не проверямо на практике... а в этом случае грош цена лбому забитию...
====
2(79) ай... Я теще тоже говорю, что если бы каждый предыдущий экстремальный сезон обуславливал бы последующий экстремальный, то у нас никогда бы не было исключений, когда вслед за супержарким летом или суперхолодной зимой, все равно случается мягкая зима или прохладное лето.

Все равно похоже каждый живет в своем собственном средневековье, а 1Сники так вообще сознательно выбирают в нем жить.

(71) Фиг его знает, конечно, есть там план или нет. :))
Но некоторые действия с запросами иногда приводили к неожиданным результатам на файловой.

Например, если в файловой базе ведется учет по характеристикам и запросы с условиями вида "Номенклатура В (&СписокНоменклатуры) И ХарактеристикаНоменклатуры В (&СписокХарактеристик)" выполняются долго, то замена этого условия на условие "ЛОЖЬ ИЛИ (Номенклатура В (&СписокНоменклатуры) И ХарактеристикаНоменклатуры В (&СписокХарактеристик))" может существенно улучшить временные показатели.

(84) Какой ужас. Видать этот финт переключает анализатор запроса на ветку, которую писал человек с более прямыми руками...

(84) а внутреннее соединение еще больше улучшить, особенно на больших списках

(84) Чистоту экскперимента соблюли?

(71) в принципе согласен с тем, что говорить о том, что файловая база "выбирает план запроса" некорректно, но какой-то аналог "плана запроса", по которому выполняется запрос, в ней наверняка все-таки есть. :)

(87) а как же! :)

Думаю, если бы так было, то а) размер файла 1СД мог бы плавать - что указывало на накопление статистики - ее тоже наверное нужно где-то хранить. б) этобы означало что есть некий упрощеный движок СКЛ-сервера для файловой базы - как например в Аксессе МС Джет, однако тот факт, что сервер 1С не может хранить базу в файловом формате, а значит не содержит в себе этот движок - подвергает факт существования такого движка большому сомнению.

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

разве что за такую сущность можно принять фаловый кэш винды... :) при условии что база на Виндовом сервере лежит.

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

Кстати, о кэше...

(0) Я конечно ни разу не специалист по SQL :), но не могло ли в скуле что-нибудь "отвалиться", типа кэша?

А какие параметры сервера приложений?
Что будет если 1С запускать прямо на сервере приложений?
С какой скоростью копируется большой файл с сервера СУБД на сервер приложений?

>>> какая версия УПП...

Платформа 8.2.13.202, УПП 1.3.5.1

>>> скуль вариант у вас разнесен на 2-х машинах (скуль сервер и сервер 1с) - т.е данные по сети гоняются во втором случае файловой базу у вас все на одном компе крутится)

Толи я как-то не так пишу, толи вы видите то, что хотите видеть. Эксперимент 2 и 3:

1С запускается с рабочей машины -> Сервер приложений 1С -> Сервер, где база sql и файловая лежат на одном винте в соседних папочках.

>>> Я конечно ни разу не специалист по SQL :), но не могло ли в скуле что-нибудь "отвалиться", типа кэша?

Нет, у нас есть специалист по SQL, там все в порядке. Нагрузки на винт вообще нет, проц максимум поднимается до 70% если делать выгрузку/загрузку dt-шника, память тоже всегда свободная есть - загрузка не выше 80%. Нагрузка сети не выше 15%.

>>>Что будет если 1С запускать прямо на сервере приложений?

Клиент 1С у нас там не стоит, только сервер.

>>> С какой скоростью копируется большой файл с сервера СУБД на сервер приложений?

Скорость загрузки файла с сервера sql на сервер 1с ~130-140 мб/с. Гигабайтный dt-шник копируется ~9 секунд.
Скорость отправки файла с сервера 1с на сервер sql такая же. Тот же самый dt-шник - тоже самое время.

Поставили клиент на сервер приложений. Запустил тест оттуда. Опять две базы на одном сервере: sql и файловая, в обеих кроме меня ни души. Результаты те же...

(0) режим управления блокировками какой стоит?

(96) замер производительности 1сный запустится или нет?

2(98) зачем? сказано ведь - "Нет, у нас есть специалист по SQL, там все в порядке"
===
на всякий случай - держу в руках табличку "Сарказм"

я видел реально в замерах производительности код выполняется столько же времени (файловый vs скуль). но при этом секундомер показывает другие данные.

а все-таки надо запустить... запросы сильно по разному работают (например в (&список) если в списке много элементов)

2(100,101) э... значение слова "Сарказм" известно?

(102) я писал для автора топика.. ;)

а я... а мне...

(0)
Отчеты какие-нить тяжелые сравнивал по скорости?

(0) v8: Приглашаю на вебинар "ускорение 1С..."

Замер производительности:
http://wallpapercube.net/file.png
http://wallpapercube.net/sql.png

найдем 10 отличий?

(107) а чОйта за внешние обработины используются?

Угу. Что за темповский файл съедает 99,97% времени?

а вооще - пилить и пилить запрос надо

(110) это скорее всего внешняя обработка

>>> а чОйта за внешние обработины используются?

А х.з. конфа типовая. Что там пишется в этот темп-файл....

поставь галку "для вызова процедур включать общее время выполнения" - увидишь, что за фигня

2(113) вот видишь - узкое место нашел... теперь разбирайся с ним, исследуй, думай как избежать

только наверное нужно еще включить режим -debug на сервере 1С

Почему это узкое место появляется только при работе с sql и так жутко тормозит?

(117) потому что запросы выполняются по разному

а вообще - нужно сначала узнать, что же оно там выполняет

2(117) пока непонятно... Работай дальше в этом направлении

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

2(121) вы одно с автором лицо?

у меня тмпшная фигня - время работы внешних обработок (тех, что из справочника "внешние обработки"), только что проверил

(122) нет. это к вопросу о включении -debug

(122), (124) ждем скрина с галочкой из (114)

ну почему?.. лааай-рулай...(Земфира)

(0) Всегда так было... Я даже 2 базы умею распределенки, одна скл, другая для перепроведения - файловая. разница при проведениии месяца скл - 12 ч. файловая 8 ч. :)

(0) а на (97) не ответишь?

>>> режим управления блокировками какой стоит?

Управляемый.

(129) а попробуй автоматический поставить на скульной..Так в виде эксперимента.. Очень интересен результат

(99)Табличку в студию.Я тож думал , что специалист SQLный, пока УПП не поставил.

(0) перепроведение да, но тоже до того момента пока база не превысят размер внутреннего файла.

З.Ы.
Одновременная работа пользователей в файловом варианте будет тормознее в 500 раз ;)

2(131):
http://www.youtube.com/watch?v=DF7MroTLDfU
2 минуты 5 секунд

(0)
Все проблемы решаются, только различными способами.
Ключевой момент - почему сервер СУБД не использует все ресурсы, и где узкое место.
В однопользовательском режиме файловая версия почти всегда быстрее SQL.
Если у кого-то есть сомнения что происходит и причины проблем, обращайтесь: softpoint.ru
Там есть интересные статьи про проблемы, решения и примеры ситуаций в реальных системах клиентов.

Кстати проблему с Партиями тоже можно решить, чтобы было быстро и не было блокировок. Есть реальные примеры.

(0)Перепровожу месяц в скуле(УПП).Результат - на 5-10% медленне чем в файловой особенно когда последние доки.
Сильно увеличивается файл логов в Temp.db(на отдельном диске вынесен).Забирает понемногу память(это проблема 1С-таблицы распухают)При критическом увеличении памяти 1С выдаст "Не хватает памяти".Все крутится по трехзвенки на 32 битах.SQL видит память на AWE.
Время перепроведения примерно 20 часов.(В файловой примерно 18 часов).
Думаю , если переведу все на 64б., будет эффект.
Может всеж Вам к Гилеву зайти.

>>> (122), (124) ждем скрина с галочкой из (114)

Там всё тоже самое:

http://wallpapercube.net/sql2.png

А вот тот самый файлик, работа с которым сжирает почти 100%:

http://wallpapercube.net/v8_F22D_26.tmp

В файловой версии он тоже есть, но забирает всего 1,5% от общей производительности.

А вот обработка, которую я запускаю.
http://wallpapercube.net/PPP.epf

2(138) тмп-файл это и есть обработка, которую ты запускаешь

и это... ты не хочешь обновиться хотя бы до последней 8.1.

(139) Почему именно он, в такой маленький размер разве что-то влезет? При запуске создается куча таких файлов (есть и по 1,8 метра), но грузит именно эта малипуська.

2(141) потому что твоя обработка из (138) имеет точно тако же размер и точно такое же содержание.
http://screencast.com/t/zZGqaVwj

Вот и смотри ее код и что она делает

http://screencast.com/t/4wlh6w2DoN

знач см (116)

ну так и смотри функцию УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров

а она, небось, на сервере выполняется, так что мы возвращаемся к (116)

Вобщем, выходит, что две функции "ПолучитьДеревоПартийНаСкладахУпр()" + "ПолучитьДеревоПартийНаСкладахБух()" съедают больше 80% всего времени выполнения.

На последнюю строку в этих функциях приходится по ~40%:

Возврат Запрос.Выполнить().Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкам);

Процентное соотношение одинаково и в файловой и в sql.

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

(148) чудес не бывает =) релиз конфы какой? у скуля есть "тормоза" в одном частом случае, когда идет частое обращение к реквизитам через точку, что вызывает за собой получение всего объекта..

(149) писал выше 1.3.5.1

(148) надо курить тексты запросов в консоли... как-то ускорил в 15 раз какой-то запрос по партиям из УПП (по-моему даже в дискуссии с Живой Ископаемый )

(148) Не знаю , имеет ли это отношение к основному вопросу.
Но
Возврат Запрос.Выполнить().Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкам);

- предполагает запрос с итогами. Время выполнения такого запроса может отличаться для одного и того же количества данных - в десятки раз и зависит от характера повторений значений в колонках итогов.

Например, в исходной таблице колонка Организация содержит только одно значение , то тогда при использовании ИТОГОВ по этой колонке  в выходную таблицу запроса добавится только одна запись.
Если же колонка Организация содержит тысячу разных значений , то в выходную таблицу добавится 1000 записей.

а сколько памяти на сервере приложений?

(153) 8 гигов.